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方式 来 阐述 高 水 准 的 Android 应 用 开发 要 点 。 本 书 从 三 个 方面 来 组 织 内 
容 。 第 一 ， 介 绍 Android 开 发 者 不 容易 掌握 的 一 些 知 识 点 ， 第 二 ， 结 合 
Android 源 代码 和 应 用 层 开发 过 程 ， 融 会 贯通 ， 介 绍 一 些 比 较 深入 的 知 
识 点 ; 第 三 ， 介 绍 一 些 核心 技术 和 Android 的 性 能 优化 思想 。 


本 书 侧重 于 Android 知 识 的 体系 化 和 系统 工作 机 制 的 分 析 ， 通 过 本 
书 的 学 习 可 以 极 大 地 提高 开发 者 的 Android 技 术 水 平 ， 从 而 更 加 高 效 地 
成 为 高 级 开发 者 。 而 对 于 高 级 开发 者 来 说 ， 仍 然 可 以 从 本 书 的 知识 体 
系 中 获 益 。 


序言 


与 玉 刚 共事 两 年 ， 其 对 技术 的 热情 和 执著 让 人 敬佩 ， 其 技术 进步 
之 快 又 让 人 人 惊叹。 如今 ， 他 把 所 掌握 的 知识 与 经 验 成 书 出 版 ， 是 一 件 
R228: 于 作者 ， 此 书 是 他 的 心血 所 成 ， 可 喜 可 贺 ; 于 读者 ， 可 
解 “ 工 作 视野 ”之 困 与 “ 百 思 不 得 其 解 * 之 惑 ， 或 许 有 “ 啊 哈 ， 原 来 如 
此 ”之 效 ， 又 或 许 有 “技能 +1? 之 得 意 一 笑 。 


玉 刚 拥有 丰富 的 Android 开 发 经 验 ， 对 Android 开 发 的 很 多 知识 点 
都 有 深入 研究 ， 我 相信 此 书 定 能 为 读者 市 来 惊喜 。 书 的 内 容 ， 大 抵 有 
WU FILAM: 基础 知识 点 之 深入 理解 (例如 ，Activity 的 生命 周期 和 启 
动 模 式 、Android 的 消息 机 制 分 析 、View 的 事件 体系 、View 的 工作 原 
HET); 不 常见 知识 点 的 分 析 〈 例 如 ，IPC 机 制 、 理 解 Window 和 
WindowManager EW) ; 工程 实践 中 的 经 验 (PIG, SRA BOK ` 
Android 性 能 优化 等 章节 ) 。 因 此 ， 此 书 读者 需要 有 一 定 的 Android 开 
发 基础 和 工程 经 验 ， 否 则 读 起 来 会 比较 吃力 或 者 感觉 云 里 筋 里 。 对 于 
想 成 长 为 高 级 或 者 资深 Android 研 发 的 工程 师 ， 书 中 的 知识 点 都 是 需要 
掌握 的 。 


最 后 ， 项 望 读者 能 够 从 此 书 获 益 ， 接 触 到 一 些 工 作 中 未 曾 了 解 或 
者 思考 的 知识 点 。 更 进一步 ， 希 望 读 者 能 够 活 学 活用 ， 并 学 习 此 书 背 
后 的 钻研 精神 。 
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从 目前 的 形势 来 看 ，Android 开 发 相当 火热 ， 但 是 高 级 Android 开 
发 人 才 却 比较 少 ， 当 然 在 国内 ， 不 仅仅 是 Android， 其 他 技术 六 位 同样 
面临 这 个 问题 。 试 想 下 ， 如 采 有 一 本 书 能 够 切实 有 效 地 提高 开发 者 的 
技术 水 平 ， 那 该 多 好 啊 ! 纵 观 市 场 上 的 Android 书 籍 ， 很 多 都 是 入 门类 
书籍 ， 还 有 一 些 Android 源 码 分 析 、 系 统 移植 、 驱 动 开发 、 逆 同 工 程 等 
系统 底层 类 书籍 。 入 门类 书籍 是 目前 图 书市 场 中 的 中 坚 力 量 ， 它 们 在 
帮助 开发 者 入 门 的 过 程 中 起 到 了 非常 重要 的 作用 ， 但 开发 者 春 想 进 一 
步 提 高 技术 水 平 ， 还 需要 阅读 更 深入 的 书籍 。 撒 层 书籍 包括 源码 分 
析 、 张 动 开 发 、 逆 癌 工 程 等 书籍 ， 它 们 从 撒 层 或 者 某 一 个 特殊 的 角度 
来 深入 地 分 析 Android， 这 是 很 值得 称赞 和 学 习 的 ， 通 过 这 些 书 可 以 极 
大 地 提高 开发 者 故 层 或 者 相关 领域 的 技术 水 平 。 但 美中不足 的 是 ， 系 
统 底 层 书 籍 比 较 偏 理 论 ， 部 分 开发 者 阅读 起 来 可 能 会 有 点 睡 深 难 懂 。 
更 重要 的 一 点 ， 由 于 它们 往往 侧重 原理 和 确 层 机 制 ， 导 人 致 它们 不 能 
接 为 应 用 层 开发 服务 ， 毕 竟 绝 大 多 数 Android 开 发 岗位 都 是 应 用 层 开 
发 。 由 于 阅读 瓜 层 类 书籍 一 般 只 能 够 加 深 对 底层 的 认识 ， 而 在 应 用 层 
开发 中 ， 还 十 不 能 形成 直接 有 效 的 战斗 力 ， 这 中 间 是 需要 转化 过 程 
的 。 但 是 ， 由 于 部 分 开发 者 缺乏 相应 的 技术 功 确 ， 导 致 无 法 完成 这 个 
转化 过 程 。 


可 以 发 现 ， 目 前 市 场 上 既 能 够 极 大 地 提高 开发 者 的 应 用 层 技术 经 
验 ， 双 能够 将 上 层 和 系统 压 层 的 运行 机 制 结合 起 来 的 书籍 还 是 比较 少 
的 。 对 企业 来 说 ， 在 业务 上 有 很 强 的 技术 能 力 ， 同 时 对 Android 底 层 也 
有 一 定理 解 的 开发 人 员 ， 是 企业 比较 青睐 的 技术 高 手 。 为 了 完成 这 一 


愿望 ， 笔 者 写 了 这 本 书 。 通 过 对 本 书 的 深入 学 习 ， 开 发 者 既 能 够 极 大 
地 提高 应 用 层 的 开发 能 力 ， 又 能 够 对 Android 系 统 的 运行 机 制 有 一 定 的 
理解 ， 但 如 果 要 深入 理解 Android 的 故 层 机 制 ， 仍 然 需 要 查看 相关 源码 
分 析 的 书籍 。 


本 书 适 合 各 类 开发 者 阅读 ， 对 于 初 、 中 级 开发 者 来 说 ， 可 以 通过 
本 书 更 加 高 效 地 达到 高 级 开发 者 的 技术 水 平 。 而 对 于 高 级 开发 者 ， 仍 
然 可 以 从 本 书 的 知识 体系 中 获 益 。 本 书 的 书 名 之 所 以 采用 忆 术 这 个 
词 ， 这 是 因为 在 笔者 眼中 ， 代 码 写 到 极致 束 是 一 种 乙 术 。 


本 文 内 容 
本 书 共 15 章 ， 所 讲述 的 内 容 均 基于 Android 5.0 系 统 。 


第 1 章 介绍 Activity 的 生命 周期 和 局 动 模式 以 及 IntentFilter 的 匹配 规 
则 。 


第 2 章 介 绍 Android 中 常见 的 IPC 机 制 ， 多 进程 的 运行 模式 和 一 些 常 
见 的 进程 则 通信 方式 ， 包 括 Messenger、AIDL 、Binder 以 及 
ContentProvider 等 ， 同 时 还 介绍 Binder 连 接 池 的 概念 。 


第 3 章 介 绍 View 的 事件 体系 ， 并 对 View 的 基础 知识 、 滑 动 以 及 弹 
性 渭 动 做 详细 的 介绍 ， 同 时 还 深入 分 析 滑 动 冲突 的 原因 以 及 解决 方 
法 。 


第 4 章 介 绍 View 的 工作 原理 ， 首 先 介 绍 ViewRoot、DecorView、 
MeasureSpec 等 Yiew 相 关 的 底层 概念 ， 然 后 详细 分 析 View 的 测量 、 布 
局 和 绘制 二 大 流程 ， 最 后 介绍 自 定 义 View 的 分 类 以 及 实现 思想 。 


第 5 章 讲 述 一 个 不 常见 的 概念 RemoteViews , o> Al + yi 
RemoteViews 在 通知 栏 和 桌面 小 部 件 中 的 使 用 场景 ， 同 时 还 详细 介绍 
PendingIntent， 最 后 深入 分 析 RemoteViews 的 内 部 机 制 并 探索 性 地 指出 
RemoteViews 在 Android 中 存在 的 意义 。 


第 6 章 对 Android 的 Drawable 做 一 个 全 面 性 的 介绍 ， 除 此 之 外 还 讲 
解 自 定义 Drawable 的 方法 。 


第 7 草 对 Android 中 的 动画 做 一 个 全 面 深入 的 分 析 ， 包 仿 View 动 画 
和 属性 动画 。 


第 8 草 讲述 Window 和 WindowManager， 首 先 分 机 Window 的 内 部 工 
作 原 理 ， 包 括 Window 的 添加 、 更 新 和 删除 ， 其 次 分 析 Activity、Dialog 
等 类 型 的 Window 对 象 的 创建 过 程 。 


第 9 章 深 入 分 析 Android 中 四 大 组 件 的 工作 过 程 ， 主 要 包括 四 大 组 
件 的 运行 状态 以 及 它们 主要 的 工作 过 程 ， 比 如 局 动 、 绑 定 、 广 播 的 发 
送 和 接收 等 。 


第 10 章 深入 分 析 Android 的 消息 机 制 ， 其 中 涉及 的 概念 有 
Handler、Looper、MessageQueue 以 及 ThreadLocal， 此 外 还 分 析 主 线程 
的 消息 循环 模型 。 


第 11 章 讲述 Android 的 线程 和 线程 池 ， 首 和 爷 介绍 AsyncTask ` 
HandlerThread > IntentService 以 及 ThreadPoolExecutor 的 使 用 方法 ， 然 
后 分 析 它 们 的 工作 原理 。 


第 12 章 讲述 的 主题 是 Bitmap 的 加 载 和 缓存 机 制 ， 首 移 讲述 高 效 加 
载 图 片 的 方式 ， 接 着 介绍 LruCache 和 DiskLruCache 的 使 用 方法 ， 最 后 


通过 一 个 ImageLoader 的 实例 来 将 它们 综合 起 来 。 


第 13 章 是 综合 技术 ， 讲 述 一 些 很 重要 但 是 不 太 常 见 的 技术 方案 ， 
它们 是 CrashHandler、multidex、 插 件 化 以 及 反 编 译 。 


第 14 章 的 主题 是 JNI 和 NDK 编 程 ， 介 绍 使 用 JNI 和 Android NDK 编 
程 的 方法 © 


第 15 章 介绍 Android 的 性 能 优化 方法 ， 比 如 靖 见 的 布局 优化 、 绘 制 
优化 、 内 存 泄 露 优化 等 ， 除 此 之 外 还 介绍 分 析 ANR 和 内 存 泄露 的 方 
法 ， 最 后 探讨 如 何 提高 程序 的 可 维护 性 这 一 话题 。 


通过 这 15 章 的 学 习 ， 可 以 让 初 、 中 级 开发 者 的 技术 水 平和 把 探 能 
力 提 升 一 个 档次 ， 最 终 成 为 高 级 开发 者 。 


本 书 特色 


本 书 定位 为 进 阶 类 图 书 ， 不 会 对 一 些 基础 知识 从 头 说 起 ， 或 者 说 
每 一 章 世 都 不 镁 凋 各 种 入 门 知识 ， 但 是 在 同 高 级 知识 点 过 渡 的 时 候 ， 
会 稍微 提 及 一 下 基础 知识 从 而 做 到 平滑 过 渡 。 开 发 者 在 掌握 入 门 知识 
以 后 ， 通 过 本 书 可 以 极 大 地 提高 应 用 层 开 发 的 技术 水 平 ， 同 时 还 可 以 
理解 一 定 的 Android 改 层 运 行 机 制 ， 并 且 能 够 将 它们 进行 升华 从 而 更 好 
地 为 应 用 层 开 发 服务 。 除 了 这 些 ， 开 发 者 还 可 以 掌握 一 些 核心 技术 和 
性 能 优化 思想 ， 本 书 涉及 的 知识 ， 都 是 一 个 合格 的 高 级 工程 师 所 必须 
掌握 的 。 人 简单 地 说 ， 本 书 的 目的 整 是 让 初 、 中 级 开发 者 更 有 和 针对 性 地 
掌握 高 级 工程 师 所 应 该 掌握 的 技术 ， 能 够 让 初 、 中 级 开发 者 按照 正确 
的 道路 快速 地 成 长 为 高 级 工程 师 。 
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第 1 章 ”Activity 的 生命 周期 和 局 动 
模式 


作为 本 书 的 第 1 章 ， 本 章 主 要 介绍 Activity 相 关 的 一 些 内 容 。 
Activity 作 为 四 大 组 件 之 首 ， 是 使 用 最 为 频繁 的 一 种 组 件 ， 中 文 直接 翻 
译 为 “活动 "»， 但 是 笔者 认为 这 种 翻译 有 些 生 硬 ， 如 果 翻 译 成 界面 就 会 
更 好 理解 。 正 常情 况 下 ， 除 了 Window、Dialog 和 Toast， 我 们 能 见 到 的 
界面 的 确 只 有 Activity。Activity 是 如 此 重要 ， 以 至 于 本 书 开 篇 瓯 不 得 
不 讲 到 它 。 当 然 ， 由 于 本 书 的 定位 为 进 阶 书 ， 所 以 不 会 介绍 如 何 启动 
Activity 这 类 入 门 知 识 ， 本 章 的 侧重 点 是 Activity 在 使 用 过 程 中 的 一 些 
不 容易 搞 清楚 的 概念 ， 主 要 包括 生命 周期 和 局 动 模式 以 及 IntentFilter 的 
匹配 规则 分 析 。 其 中 Activity 在 异常 情况 下 的 生命 周期 是 十 分 微妙 的 ， 
至 于 Activity 的 启动 模式 和 形形色色 的 Flags 更 是 让 初学 者 摸 不 到 头脑 ， 
瓯 连 隐 式 启 动 Activity 中 也 有 着 复 洒 的 Intent 匹 配 过 程 ， 不 过 不 用 担 
心 ， 本 章 接 下 来 将 一 一 解 开 这 些 疑 难 问题 的 神秘 面纱 。 


11 Activity 的 生命 周期 全 面 分 析 


本 节 将 Activity 的 生命 周期 分 为 两 部 分 内 容 ， 一 部 分 是 典型 情况 下 
的 生命 周期 ， 另 一 部 分 是 异常 情况 下 的 生命 周期 。 所 谓 典型 情况 下 的 
生命 周期 ， 是 指 在 有 用 户 参 与 的 情况 下 ，Activity 所 经 过 的 生命 周期 的 
改变 ， 而 异常 情况 下 的 生命 周期 是 指 Activity 被 系统 回收 或 者 由 于 当前 


设备 的 Configuration 发 生 改 变 从 而 导致 Activity 被 销毁 重建 ， 异 弟 情 况 
下 的 生命 周期 的 关注 点 和 典型 情况 下 略 有 不 同 。 


1.1.1 典型 情况 下 的 生命 周期 分 析 


在 正常 情况 下 ，Activity 会 经 历 如 下 生命 周期 。 


(1) onCreate: 表示 Activity 正 在 被 创建 ， 这 是 生命 周期 的 第 一 个 
方法 。 在 这 个 方法 中 ， 我 们 可 以 做 一 些 初 始 化 工作 ， 比 如 调用 
setContentView 去 加 载 界面 布局 资源 、 初 始 化 Activity 所 需 数 据 等 。 


(2) onRestart: 表示 Activity 正 在 重新 启动 。 一 般 情况 下 ， 当 当 
前 Activity 从 不 可 见 重新 变 为 可 见 状态 时 ，onRestart 束 会 被 调用 。 这 种 
情形 一 般 是 用 户 行为 所 导致 的 ， 比 如 用 户 按 Home 刍 切换 到 桌面 或 者 用 
户 打 开 了 一 个 新 的 Activity， 这 时 当前 的 Activity 束 会 暂停 ， 也 就 是 
onPause 和 onStop 被 执行 了 ， 接 着 用 户 又 回 到 了 这 个 Activity， 束 会 出 现 
这 种 情况 。 


(3) onStart 表示 Activity 正 在 被 启动 ， 即 将 开始 ， 这 时 Activity 
已 经 可 见 了 ， 但 是 还 没有 出 现在 前 人 台 ， 还 无 法 和 用 户 交 互 。 这 个 时 候 
其 实 可 以 理解 为 Activity 已 经 显示 出 来 了 ， 但 是 我 们 还 看 不 到 。 


(4) onResume: 表示 Activity 已 经 可 见 了 ， 并 且 出 现在 前 台 并 开 

台 活 动 。 要 注意 这 个 和 onStart 的 对 比 ，onStart 和 onResume 都 表示 

Activity 已 经 可 见 ， 但 是 onStart 的 时 候 Activity 还 在 后 台 ，onResume 的 
时 候 Activity 才 显示 到 前 台 。 


(5) onPause: 表示 Activity 正 在 停止 ， 正 常情 况 下 ， 紧 接着 
onStop 吏 会 被 调用 。 在 特殊 情况 下 ， 如 果 这 个 时 候 快速 地 再 回 到 当前 
Activity， 那 么 onResume 会 被 调用 。 笔 者 的 理解 是 ， 这 种 情况 属于 极端 
情况 ， 用 户 操作 很 难 重 现 这 一 场景 。 此 时 可 以 做 一 些 存储 数据 、 停 止 
动画 等 工作 ， 但 是 注意 不 能 太 耗 时 ， 因 为 这 会 影响 到 新 Activity 的 显 
示 ，onPause 必 须 先 执行 完 ， 新 Activity 的 onResume 才 会 执行 。 


(6) onStop: 表示 Activity 即 将 停止 ， 可 以 做 一 些 稍微 重量 级 的 
回收 工作 ， 同 样 不 能 太 耗 时 。 


(7) onDestroy: 表示 Activity 即 将 被 销毁 ， 这 是 Activity 生 命 周 期 
中 的 最 后 一 个 回调 ， 在 这 里 ， 我 们 可 以 做 一 些 回收 工作 和 最 终 的 资源 
释放 。 


正常 情况 下 ，Activity 的 常用 生命 周期 束 只 有 上 面 7 个 ， 图 1-1 更 评 
细 地 摘 述 了 Activity 各 种 生命 周期 的 切换 过 程 。 
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图 1-1 Activity 生 命 周 期 的 切换 过 程 


针对 图 1-1， 这 里 再 附加 一 下 具体 说 明 ， 分 如 下 儿 种 情况 。 


(1) 针对 一 个 特定 的 Activity， 第 一 次 启动 ， 回 调 如 下 : onCreate 


-> onStart -> onResume ° 


(2) 当 用 户 打 开 新 的 Activity 或 者 切换 到 桌面 的 时 候 ， 回 调 如 
下 : onPause -> onStop。 这 里 有 一 种 特殊 情况 ， 如 果 新 Activity 采 用 了 
透明 主题 ， 那 么 当前 Activity 不 会 回调 onStop。 


(3) 当 用 户 再 次 回 到 原 Activity 时 ， 回 调 如 下 : onRestart -> 


onStart -> onResume ° 


(4) 当 用 户 按 back 键 回 退 时 ， 回 调 如 下 : onPause -> onStop -> 


onDestroy ° 


(5) 当 Activity 被 系统 回收 后 再 次 打开 ， 生 命 周期 方法 回调 过 程 
和 (1) 一样， 注意 只 是 生命 周期 方法 一 样 ， 不 代表 所 有 过 程 都 一 样 ， 
这 个 问题 在 下 一 市 会 详细 说 明 。 


(6) 从 整个 生命 周期 来 说 ，onCreate 和 onDestroy 是 配对 的 ， 分 别 
标识 着 Activity 的 创建 和 销毁 ， 并 且 只 可 能 有 一 次 调用 。 从 Activity 是 
否 可 见 来 说 ，onStart 和 onStop 是 配对 的 ， 随 着 用 户 的 操作 或 者 设备 屏 
幕 的 点 亮 和 炸 灭 ， 这 两 个 方法 可 能 被 调用 多 次 ; 从 Activity 是 否 在 前 台 
来 说 ，onResume 和 onPause 是 配对 的 ， 随 着 用 户 操 作 或 者 设备 屏幕 的 
点 亮 和 烛 灭 ， 这 两 个 方法 可 能 被 调用 多 次 。 


这 里 提出 2 个 问题 ， 不 知道 大 家 征 否 清楚 。 


问题 1: onStart 和 onResume、onPause 和 onStop 从 描述 上 来 看 差 不 
多 ， 对 我 们 来 说 有 什么 实质 的 不 同 呢 ? 


问题 2: 假设 当前 Activity 为 A， 如 果 这 时 用 户 打开 一 个 新 Activity 
B， 那 么 B 的 onResume 和 A 的 onPause 哪 个 先 执行 呢 ? 


先 说 第 一 个 问题 ， 从 实际 使 用 过 程 来 说 ，onStart 和 onResume、 
onPause 和 onStop 看 起 来 的 确 差不多 ， 甚 至 我 们 可 以 只 保留 其 中 一 对 ， 
比如 只 保留 onStart 和 onStop。 既 然 如 此 ， 那 为 什么 Android 系 统 还 要 提 
供 看 起 来 重复 的 接口 呢 ? 根据 上 面 的 分 析 ， 我 们 知道 ， 这 两 个 配对 的 
回调 分 别 表示 不 同 的 意义 ，onStart 和 onStop 是 从 Activity 是 否 可 见 这 个 
角度 来 回调 的 ， 而 onResume 和 onPause 是 从 Activity 是 否 位 于 前 台 这 个 
角度 来 回调 的 ， 除 了 这 种 区 别 ， 在 实际 使 用 中 没有 其 他 明显 区 别 。 


第 二 个 问题 可 以 从 Android 源 码 里 得 到 解释 。 关 于 Activity 的 工作 
原理 在 本 书后 续 章 节 会 进行 介绍 ， 这 里 我 们 先 大 概 了 解 即 可 。 从 
Activity 的 启动 过 程 来 看 ， 我 们 来 看 一 下 系统 源码 。Activity 的 局 动 过 
程 的 源码 相当 复杂 ， 涉 及 Instrumentation > ActivityThread 和 
ActivityManagerService ( F fai PK AMS) 。 这 里 不 详细 分 析 这 一 过 
程 ， 人 简单 理解 ， 启 动 Activity 的 请 求 会 由 Instrumentation 来 处 理 ， 然 后 
它 通过 Binder 向 AMS 发 请 求 ，AMS 内 部 维护 着 一 个 ActivityStack 并 人 负 
责 栈 内 的 Activity 的 状态 同步 ，AMS 通 过 ActivityThread 去 同步 Activity 
的 状态 从 而 完成 生命 周期 方法 的 调用 。 在 ActivityStack 中 的 
resumeTopActivity-InnerLocked 方 法 中 ， 有 这 么 一 段 代码 : 


// We need to start pausing the current activity so the top 
one 
// can be resumed... 
boolean dontWaitForPause = 
(next.info.flags&ActivityInfo.FLAG_RESUME_ WHILE _PAUSING) != 0; 
boolean pausing = 
mStackSupervisor.pauseBackStacks(userLeaving, true, dontWaitForPa 


use); 


if (mResumedActivity != null) { 
pausing |= 
startPausingLocked(userLeaving, false, true, dontWait -ForPause) ; 
if (DEBUG_STATES) Slog.d(TAG, "resumeTopActivityLocked: 


Pausing " + mResumedActivity); 


} 


从 上 述 代码 可 以 看 出 ， 在 新 Activity 启 动 之 前 ， 栈 顶 的 Activity 需 
要 驳 onPause 后 ， 新 Activity 才 能 启动 。 最 终 ， 在 ActivityStackSupervisor 
中 的 realStartActivityLocked 方 法 会 调用 如 下 代码 。 


app.thread.scheduleLaunchActivity(new 
Intent(r.intent),r.appToken, 
System.identityHashCode(r),r.info,new 


Configuration(mService.mConfiguration), 


r.compat,r.task.voiceInteractor,app.repProcState,r.icicle,r.per 


sistentState, 


results, newIntents, !andResume, mService.isNextTransition- 
Forward(), 


profilerInfo); 


我 们 知道 ， 这 个 app.thread 的 类 型 是 IApplicationThread , 而 
IApplicationThread 的 具体 实现 是 ActivityThread 中 的 
ApplicationThread ° 所以， 这 段 代 码 实际 上 调 到 了 ActivityThread 的 
中 , BE ApplicationThread 的 scheduleLaunchActivity 方法 ， 而 
scheduleLaunchActivity 方法 最 终 会 完成 新 Activity 的 onCreate ` 


onStart、onResume 的 调用 过 程 。 因 此 ， 可 以 得 出 结论 ， 是 旧 Activity 移 
onPause， 然 后 新 Activity 再 启动 。 


至 于 ApplicationThread 的 scheduleLaunchActivity 方 法 为 什么 会 完成 
#1 ActivityHJonCreate ` onStart ` onResumeA Val Ate, We RATE 
码 。scheduleLaunchActivity 最 终 会 调用 如 下 方法 ， 而 如 下 方法 的 确 会 
完成 onCreate、onStart、onResume 的 调用 过 程 。 


源码 : ActivityThread#handleLaunchActivity 


private void handleLaunchActivity(ActivityClientRecord 

r,Intent custom- Intent) { 
// If we are getting ready to gc after going to the 

background, well 

// we are back active so skip it. 

unscheduleGcIdler(); 

mSomeActivitiesChanged = true; 

if (r.profilerInfo != null) { 

mProfiler.setProfiler(r.profilerInfo); 


mProfiler.startProfiling(); 


// Make sure we are running with the most recent 
config. 
handleConfigurationChanged(null, null); 
if (localLOGV) Slog.v( 
TAG, "Handling launch of " + r); 
// 这 里 新 Activity 被 创建 出 来 ， 其 onCreate 和 onStart 会 被 调用 


Activity a = performLaunchActivity(r,customIntent); 


从 上 面 的 分 析 可 以 看 出 ， 当 新 启动 一 个 Activity 的 时 候 ， 旧 
Activity 的 onPause 会 完 执 行 ， 然 后 才 会 局 动 狐 的 Activity。 到 改 是 不 是 
这 样 呢 ? 我 们 写 个 例子 验证 一 下 ， 如 下 是 2 个 Activity 的 代码 ， 在 
MainActivity 中 单 击 按钮 可 以 跳 转 到 SecondActivity， 同 时 为 了 分 析 我 
们 的 问题 ， 在 生命 周期 方法 中 打印 出 了 日 志 ， 通 过 日 志 我 们 就 能 看 出 
它们 的 调用 顺序 。 


代码 : MainActivity.java 


代码 : SecondActivity.java 


} 


我 们 来 看 一 下 log ， 是 不 是 和 我 们 上 面 分析 的 一 样 ， 如 图 1-2 所 
ZR œ 


Level Time PID TID Application Tag Text 

D 2-01 01:37:33.051 724 724 o yg.chap =! MainActivit onPause 
-01 01:37:33.11 + 724 ryg.chapter_1 SecondActivi ty  onCreate 
01 01:37:33.111 724 724 -ryg.chapter 1 SecondAct G onStart 
01 01: 33.11 724 724 -ryg.chapter 1 SecondAct 
-01 01:37:33.43 4 4 ryg.chapt E MainActivit Stop 


图 1-2 Activity 生命 周期 方法 的 回调 顺序 


通过 图 1-2 可 以 发 现 ， 旧 Activity 的 onPause 移 调用 ， 然 后 新 Activity 
才 局 动 ， 这 也 证 实 了 我 们 上 面 的 分 析 过 程 。 也 许 有 人 会 问 ， 你 只 是 分 
析 了 Android5.0 的 源码 ， 你 怎么 知道 所 有 版 本 的 源码 都 是 相同 逻辑 
ME? 关于 这 个 问题 ， 我 们 的 确 不 大 可 能 把 所 有 版 本 的 源码 都 分 析 一 
裔 ， 但 是 作为 Android 运 行 过 程 的 基本 机 制 ， 随 着 版 本 的 更 新 并 不 会 有 
大 的 调整 ， 因 为 Android 系 统 也 需要 兼容 性 ， 不 能 说 在 不 同 版 本 上 同一 
个 运行 机 制 有 着 截然 不 同 的 表现 。 关 于 这 一 点 我 们 需要 把 握 一 个 度 ， 
瓯 是 对 于 Android 运 行 的 基本 机 制 在 不 同 Android 版 本 上 上 有 具有 延续 性 。 
从 另 一 个 角度 来 说 ，Android 官 方 文档 对 onPause 的 解释 有 这 么 一 句 : 
不 能 在 onPause 中 做 重量 级 的 操作 , 为 必须 onPause 执 行 完 成 以 后 新 
Activity 才 能 Resume， 从 这 一 点 也 能 间接 证 明 我 们 的 结论 。 通 过 分 析 这 
个 问题 ， 我 们 知道 onPause 和 onStop 都 不 能 执行 耗 时 的 操作 ， 尤 其 是 
onPause， 这 也 意味 着 ， 我 们 应 当 尽 量 在 onStop 中 做 操作 ， 从 而 使 得 新 
Activity 尽 快 显示 出 来 并 切换 到 前 人 台 。 


11.2 异常 情况 下 的 生命 周期 分 析 


上 一 节 我 们 分 析 了 典型 情况 下 Activity 的 生命 周期 ， 本 市 我 们 接着 
分 析 Activity 在 异常 情况 下 的 生命 周期 。 我 们 知道 ，Activity 除 了 受用 
户 操作 所 导致 的 正常 的 生命 周期 方法 调度 ， 还 有 一 些 异 稍 情 况 ， 比 如 
当 资 源 相关 的 系统 配置 发 生 改变 以 及 系统 内 存 不 足 时 ，Activity 束 可 能 
BATE > 下 面 我 们 具体 分 析 这 两 种 情况 。 


1. 情况 1: 资源 相关 的 系统 配置 发 生 改变 导致 Activity 被 杀 死 并 重 
新 创建 


理解 这 个 问题 ， 我 们 首先 要 对 系统 的 资源 加 载 机 制 有 一 定 了 解 ， 

这 里 不 详细 分 析 系 统 的 资源 加 载 机 制 ， 只 是 简单 说 明 一 下 。 拿 最 简单 
的 图 厂 来 说 ， 当 我 们 把 一 张 图 片 放 在 drawable 目 录 后 ,就 可 以 通过 
Resources 去 获取 这 张 图 片 。 同 时 为 了 兼容 不 同 的 设备 ， 我 们 可 能 还 需 
要 在 其 他 一 些 目 录放 置 不 同 的 图 片 ， 比 如 drawable-mdpi ` drawable- 
hdpi、drawable-land 等 。 这 样 ， 当 应 用 程序 启动 时 ， 系 统 束 会 根据 当前 
设备 的 情况 去 加 载 合适 的 Resources 资 源 ， 比 如 说 横 屏 手机 和 坚 屏 手机 
会 拿 到 两 张 不 同 的 图 片 ( 设 定 了 landscape 或 者 portrait 状 态 下 的 
F) 。 比 如 说 当前 Activity 处 于 竖 屏 状态 ， 如 果 突 然 旋转 屏幕 ， 由 于 系 
统 配置 发 生 了 改变 ， 在 默认 情况 下 ，Activity 束 会 被 销毁 并 且 重 新 创 
建 ， 当 然 我 们 也 可 以 阻止 系统 重新 创建 我 们 的 Activity。 


在 默认 情况 下 ， 如 果 我 们 的 Activity 不 做 特殊 处 理 ， 那 么 当 系 统 配 
置 发 生 改变 后 ，Activity 束 会 被 销毁 并 重新 创建 ， 其 生命 周期 如 图 1-3 
PS 
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图 1-3 ”异常 情况 下 Activity 的 重建 过 程 


当 系 统 配置 发 生 改 变 后 ，Activity 会 被 销毁 ， 其 onPause、onStop ` 
onDestroy 均 会 补 调 用 ， 同 时 由 于 Activity 是 在 异常 情况 下 终止 的 ， 系 统 
会 调用 onSaveInstanceState 来 保存 当前 Activity 的 状态 。 这 个 方法 的 调 
用 时 机 是 在 onStop 之 前 ， 它 和 onPause 没 有 既定 的 时 序 关 系 ， 它 既 可 能 
在 onPause 之 前 调用 ， 也 可 能 在 onPause 之 后 调用 。 需 要 强调 的 一 点 
是 ， 这 个 方法 只 会 出 现在 Activity 被 异常 终止 的 情况 下 ， 正 常情 况 下 系 
统 不 会 回调 这 个 方法 。 当 Activity 被 重新 创建 后 ， 系 统 会 调用 
onRestoreInstanceState， 并 且 把 Activity 销 毁 时 onSaveInstanceState 方 法 
所 保存 的 Bundle 对 象 作 为 参数 同时 传递 给 onRestoreInstanceState 和 
onCreate 方 法 。 因 此 ， 我 们 可 以 通过 onRestoreInstanceState 和 onCreate 
方法 来 判断 Activity 是 否 补 重建 了 ， 如 采 被 重建 了 ， 那 么 我 们 就 可 以 取 
出 之 前 保存 的 数据 并 恢复 ， 从 时 序 上 来 说 ，onRestoreInstanceState 的 调 
用 时 机 在 onStart 之 后 。 


同时 ， 我 们 要 知道 ， 在 onSavelnstanceState 和 
onRestoreInstanceState 方 法 中 ， 系 统 目 动 为 我 们 做 了 一 定 的 恢复 工作 。 
当 Activity 在 异常 情况 下 需要 重新 创建 时 ， 系 统 会 默认 为 我 们 保存 当前 


Activity 的 视图 结构 ， 并 且 在 Activity 重 启 后 为 我 们 恢复 这 些 数据 ， 比 
如 文本 框 中 用 户 输入 的 数据 、ListView 滚 动 的 位 置 等 ， 这 些 View 相 关 
的 状态 系统 都 能 够 默认 为 我 们 恢复 。 具 体 针 对 某 一 个 特定 的 View 系 统 
能 为 我 们 恢复 哪些 数据 ， 我 们 可 以 查看 View 的 源码 。 和 Activity 一 样 ， 
个 View #8 # onSavelnstanceState 和 onRestoreInstanceState 这 两 个 方 
法 ， 看 一 下 它们 的 具体 实现 ， 束 能 知道 系统 能 够 目 动 为 每 个 View 恢 复 
哪些 数据 。 


关于 保存 和 恢复 View 层 次 结构 ， 系 统 的 工作 流程 是 这 样 的 ;首先 
Activity 被 意外 终止 时 ，Activity 会 调用 onSaveInstanceState 去 保存 数 
据 ， 然 后 Activity 会 委托 Window 去 保存 数据 ， 接 着 Window 再 委托 它 上 
面 的 顶级 容器 去 保存 数据 。 顶 层 容器 是 一 个 ViewGroup ， 一 般 来 说 它 
很 可 能 是 DecorView。 最 后 顶层 容器 再 去 一 一 通知 它 的 子 元 素来 你 存 
数据 ， 这 样 整个 数据 保存 过 程 束 完成 了 。 可 以 发 现 ， 这 是 一 种 典型 的 
委托 思想 ， 上 层 委 托 下 层 、 父 容器 委托 子 元 素 去 处 理 一 件 事 情 ， 这 种 
思想 在 Android 中 有 很 多 应 用 ， 比 如 View 的 绘制 过 程 、 事 件 分 发 等 都 是 
采用 类 似 的 思想 。 至 于 数据 恢复 过 程 也 是 类 似 的 ， 这 里 就 不 再 重复 介 
绍 了 。 接 下 来 举 个 例子 ， 拿 TextView 来 说 ， 我 们 分 析 一 下 它 到 底 保 存 
了 哪些 数据 。 


源码 : TextView#onSavelnstanceState 


@Override 

public Parcelable onSavelnstanceState() { 
Parcelable superState = super.onSavelnstanceState(); 
// Save state if we are forced to 
boolean save = mFreezesText; 


int start = 0; 


从 上 述 源 码 可 以 很 容易 看 出 ，TextView 保 存 了 目 己 的 文本 选中 状 
态 和 文本 内 容 ， 并 且 通 过 查看 其 onRestoreInstanceState 方 法 的 源码 ， 可 
以 发 现 它 的 确 恢复 了 这 些 数据 ， 有 具体 源码 残 不 再 贴 出 了 ， 读 者 可 以 去 
看 看 源码 。 下 面 我 们 看 一 个 实际 的 例子 ， 来 对 比 一 下 Activity 正 常 终止 
和 异常 终止 的 不 同 ， 同 时 验证 系统 的 数据 恢复 能 力 。 为 了 方便 ， 我 们 
选择 旋转 屏幕 来 异常 终止 Activity， 如 图 1-4 所 示 。 
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图 1-4 Activity 旋 转 屏幕 后 数据 的 保存 和 恢复 


通过 图 1-4 可 以 看 出 ， 在 我 们 选择 屏幕 以 后 ，Activity 补 销毁 后 重 
新 创建 ， 我 们 输入 的 文本 “这 是 测试 文本 ”被 正确 地 还 原 ， 这 说 明 系 统 


的 确 能 够 目 动 地 做 一 些 View 层 次 结构 方面 的 数据 存储 和 恢复 。 下 面 再 
用 一 个 例子 ， 来 验证 我 们 目 己 做 数据 存储 和 恢复 的 情况 ， 代 码 如 下 : 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 
if (savedInstanceState != null) { 
String test = 
savedInstanceState.getString("extra_test"); 


Log.d(TAG, "[onCreate]restore extra_test:" + 


test); 
} 
} 
@Override 


protected void onSaveInstanceState(Bundle outState) { 
super .onSavelnstanceState(outState); 
Log.d(TAG, "onSaveInstanceState"); 
outState.putString("extra_test","test"); 
} 
@Override 
protected void onRestoreInstanceState(Bundle 
savedInstanceState) { 
super.onRestoreInstanceState(savedInstanceState); 
String test = 
savedInstanceState.getString("extra_test"); 


Log.d(TAG, "[onRestoreInstanceState]restore extra_test:" 


+ test); 


} 
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符 串 ， 然 后 当 Activity 被 销毁 并 重新 创建 后 ， 我 们 再 去 获取 之 前 存储 的 
字符 串 。 接 收 的 位 置 可 以 选择 onRestoreInstanceState 或 者 onCreate， 二 
者 的 区 别 是 : onRestoreInstanceState 一 旦 和 被 调用 ， 其 参数 Bundle 
savedImstanceState 一 定 是 有 值 的 ， 我 们 不 用 额外 地 判断 是 否 为 空 ; 但 
是 onCreate 不 行 ，onCreate 如 果 是 正常 启动 的 话 ， 其 参数 Bundle 
savedInstanceState 为 null， 所 以 必须 要 额外 判断 。 这 两 个 方法 我 们 选择 
任意 一 个 都 可 以 进行 数据 恢复 ， 但 是 官方 文档 的 建议 是 采用 
onRestoreInstanceState 去 恢复 数据 。 下 面 我 们 看 一 下 运行 的 日 志 ， 如 图 
1-5 所 示 。 


Level PID TID Application 

D 8534 6534 com.ryg.chapter 

com. ryg.chapter 

853 com.ryg.chapter 
8534 8534 com.ryg.chapter I 

4 com.ryg.chapter 1 MainActivity [onCreate]res e extra_tes 

g 


34 om.ryg.chapter 


图 1-5 ”系统 日 志 


如 图 1-5 所 示 ，Activity 被 销毁 了 以 后 调用 了 onSaveInstanceState 来 
保存 数据 ， 重 新 创建 以 后 在 onCreate 和 onRestoreInstanceState 中 都 能 够 
正确 地 恢复 我 们 之 前 存储 的 字符 串 。 这 个 例子 很 好 地 证 明了 上 面 我 们 
的 分 析 结 论 。 针 对 onSaveInstanceState 方 法 还 有 一 点 需要 说 明 ， 那 就 是 
系统 只 会 在 Activity 即 将 被 销毁 并 且 有 机 会 重新 显示 的 情况 下 才 会 去 调 
用 它 。 考 虑 这 么 一 种 情况 ， 当 Activity 正 常 销毁 的 时 候 ， 系 统 不 会 调用 
onSavelnstanceState , 为 被 销毁 的 Activity 不 可 能 再 次 被 显示 。 这 名 
话 不 好 理解 ， 但 是 我 们 可 以 对 比 一 下 旋转 屏幕 所 造成 的 Activity 异 常 销 


毁 ， 这 个 过 程 和 正和 党 停止 Activity 是 不 一 样 的 ， 因 为 旋转 屏幕 后 ， 
Activity 被 销毁 的 同时 会 立刻 创建 新 的 Activity 实 例 ， 这 个 时 候 Activity 
有 机 会 再 次 立刻 展示 ， 所 以 系统 要 进行 数据 存储 。 这 里 可 以 简单 地 这 
么 理解 ， 系 统 只 在 Activity 寞 常 终止 的 时 候 才 会 调用 
onSaveInstanceState 和 onRestoreInstanceState 来 存储 和 恢复 数据 ， 其 他 
情况 不 会 触发 这 个 过 程 。 


2. 情况 2， 资源 内 存 不 足 导致 低 优先 级 的 Activity 被 杀 死 


这 种 情况 我 们 不 好 模拟 ， 但 是 其 数据 存储 和 恢复 过 程 和 情况 1 完全 
一 致 。 这 里 我 们 描述 一 下 Activity 的 优先 级 情况 。Activity 按 照 优 移 级 
从 高 到 低 ， 可 以 分 为 如 下 三 种 : 


(1) 前 台 Activity 一 一 正在 和 用 户 交 互 的 Activity， 优 先 级 最 高 。 


(2) 可 见 但 非 前 台 Activity 一 一 比如 Activity 中 弹出 了 一 个 对 话 
框 ， 导 致 Activity 可 见 但 是 位 于 后 台 无 法 和 用 户 直接 交互 。 


(3) 后 台 Activity 
onStop， 优 先 级 最 低 。 


已 经 被 暂停 的 Activity ， 比 如 执行 了 


当 系统 内 存 不 足 时 ， 系 统 就 会 按照 上 述 优先 级 去 杀 死 目标 Activity 
所 在 的 进程 ， 并 在 后 续 通 过 onSavelnstanceState 和 
onRestoreInstanceState 来 存储 和 恢复 数 数据 。 如 果 一 个 进程 中 没有 四 大 
组 件 在 执行 ， 那 么 这 个 进程 将 很 快 被 系统 杀 死 ， 因 此 ， 一 些 后 台 工 作 
不 适合 脱离 四 大 组 件 而 独 目 运 行 在 后 人 台中， 这 样 进 程 很 容易 被 杀 死 。 
比较 好 的 方法 是 将 后 台 工 作 放 入 Service 中 从 而 保证 进程 有 一 定 的 优先 
级 ， 这 样 就 不 会 轻易 地 被 系统 杀 死 。 


上 面 分 析 了 系统 的 数据 存储 和 恢复 机 制 ， 我 们 知道 ， 当 系统 配置 
发 生 改 变 后 ，Activity 会 被 重新 创建 ， 那 么 有 没有 办 法 不 重新 创建 呢 ? 
答案 是 有 的 ， 授 下 来 我 们 就 来 分 析 这 个 问题 。 系 统 配 置 中 有 很 多 内 
容 ， 如 果 当 某 项 内 容 发 生 改 变 后 ， 我 们 不 想 系统 重新 创建 Activity， 可 
以 给 Activity 指 定 configChanges 必 性。 比如 不 想 让 Activity 在 屏幕 旋转 
的 时 候 重 新 创建 ， 就 可 以 给 configChanges 属 性 添加 orientation 这 个 值 ， 
如 下 所 示 。 


android:configChanges="orientation" 


如 宁 我 们 想 指 定 多 个 值 ， 可 以 用 中 连接 起 来 ， 比 如 
android:configChanges="orientation|keyboardHidden" ° ARK ALE F M E 
的 项 目 是 非常 多 的 ， 下 面 介绍 每 个 项 目的 舍 义 ， 如 表 1-1 所 示 。 


表 1-1 configChanges 的 项 目 和 含义 


= x 
SIM 卡 唯 一 标识 IMSI (国际 移动 用 户 识别 码 ) 中 的 国家 代码 ， 由 三 位 数字 组 成 ， 中 国 为 460。 此 项 
标识 mec 代码 发 生 了 改变 
SIM 卡 唯 一 标识 IMSI (国际 移动 用 户 识别 码 ) 中 的 运营 商 代 码 ， 由 两 位 数字 组 成 ， 中 国 移动 TD A 
统 为 00， 中 国联 通 为 04， 中国 电信 为 03 。 此 项 标识 mne 发 生 改变 

locale 设备 的 本 地 位 置 发 生 了 改变 ， 一 般 指 切换 了 系统 语言 
touchscreen 触摸 屏 发 生 了 改变 ， 这 个 很 费解 ， 正 常情 况 下 无 法 发 生 ， 可 以 忽略 它 
keyboard 键盘 类 型 发 生 了 改变 ， 比 如 用 户 使 用 了 外 插 键 盘 
keyboardHidden 键盘 的 可 访问 性 发 生 了 改变 ， 比 如 用 户 调 出 了 键盘 
navigation 系统 导航 方式 发 生 了 改变 ， 比 如 采用 了 轨迹 球 导 航 ， 这 个 有 点 费解 ， 很 难 发 生 ， 可 以 忽略 它 
screenLayout 屏幕 布局 发 生 了 改变 ， 很 可 能 是 用 户 激活 了 另外 一 个 显示 设备 
fontScale 系统 字体 缩放 比例 发 生 了 改变 ， 比 如 用 户 选 择 了 一 个 新 字号 
uiMode 用 户 界 面 模式 发 生 了 改变 ， 比 如 是 否 开局 了 夜间 模式 CAPI S 新 添加 ) 
orientation 屏幕 方向 发 生 了 改变 ， 这 个 是 最 常用 的 ， 比 如 旋转 了 手机 屏幕 

当 屏 幕 的 尺寸 信息 发 生 了 改变 ， 当 旋转 设备 屏幕 时 ， 屏 幕 尺 寸 会 发 生变 化 ， 这 个 选项 比较 特殊 ， 它 
screenSize 和 编译 选项 有 关 ， 当 编译 选项 中 的 minSdkVersion 和 targetSdk Version 均 低 于 13 时 ， 此 选项 不 会 导致 
Activity 重启 ， 否 则 会 导致 Activity 重启 (API13 新 添加 ) 

设备 的 物理 屏幕 尺寸 发 生 改 变 ， 这 个 项 目 和 屏幕 的 方向 没关系 ， 仅 仅 表示 在 实际 的 物理 屏幕 的 尺寸 
改变 的 时 候 发 生 ， 比 如 用 户 切 换 到 了 外 部 的 显示 设备 ， 这 个 选项 和 screenSize 一 样 ， 当 编译 选项 中 的 
minSdkVersion 和 targetSdkVersion 均 低 于 13 时 ， 此 选项 不 会 导致 Activity HA, ATMS FH Activity 
重启 CAPI 13 新 添加 ) 
当 布局 方向 发 生变 化 , 这 个 属性 用 的 比较 少 , 正常 情况 下 无 须 修 改 布局 的 layoutDirection 属性 CAPI 

17 新 添加 ) 


smallestScreenSize 


layoutDirection 


从 表 1-1 可 以 知道 ， 如 果 我 们 没有 在 Activity 的 configChanges 属 性 
中 指定 该 选项 的 话 ， 当 配置 发 生 改 变 后 就 会 导致 Activity 重 新 创建 。 上 
面 表 格 中 的 项 目 很 多 ,但 是 我 们 常用 的 只 有 locale > orientation 和 
keyboardHidden 这 三 个 选项 ， 其 他 很 少 使 用 。 需 要 注意 的 是 screenSize 
和 smallestScreenSize， 它 们 两 个 比较 特殊 ， 它 们 的 行为 和 编译 选项 有 
关 ， 但 和 运行 环境 无 关 。 下 面 我 们 再 看 一 个 demo， 看 看 当 我 们 指定 了 
configChanges 属 性 后 ，Activity 是 否 真 的 不 会 重新 创建 了 。 我 们 所 要 修 
改 的 代码 很 简单 ， 只 需要 在 AndroidMenifest,xml 中 加 入 Activity 的 声明 
即 可 ， 代 码 如 下 : 


<uses-sdk 
android:minSdkVersion="8" 
android: targetSdkVersion="19" /> 
<activity 
android: name="com.ryg.chapter_1.MainActivity" 
android: configChanges="orientation|screenSize" 
android: label="@string/app_name" > 
<intent-filter> 
<action 
android: name="android.intent.action.MAIN" /> 
<category 
android: name="android.intent.category.LAUNCHER" /> 
</intent-filter> 
</activity> 
@Override 


public void onConfigurationChanged(Configuration newConfig) 


super .onConfigurationChanged(newConfig); 
Log.d(TAG, "onConfigurationChanged,newOrientation:" + 
newConfig.orientation); 


} 


需要 说 明 的 是 ， 由 于 编译 时 笔者 指定 的 minSdkVersion 和 
targetSdkVersion 有 一 个 大 于 13， 所 以 为 了 防止 旋转 屏幕 时 Activity 重 
局 ， 除 了 orientation， 我 们 还 要 加 上 screenSize， 原 因 在 上 面 的 表格 里 
已 经 说 明了 。 其 他 代码 还 是 不 变 ， 运 行 后 看 看 log， 如 图 1-6 所 示 。 


Level PID TID Application Tag Text 
3565 3565 com.ryg.chapter_1 MainActivity onConfigurationChanged, newOrientation:2 
3565 3565 com.ryg.chapter_1 MainActivity onConfigurationChanged, newOrientation:1 


3565 3565 com.ryg.chapter_1 MainActivity onConfigurationChanged, newOrientation:2 


图 1-6 系统 日 志 


由 上 面 的 日 志 可 见 ，Activity 的 确 没 有 重新 创建 ， 并 且 也 没有 调用 
onSaveInstanceState 和 onRestoreInstanceState 来 存储 和 恢复 数据 ， 取 而 
代 之 的 是 系统 调用 了 Activity 的 onConfigurationChanged 方 法 ， 这 个 时 候 
我 们 惑 可 以 做 一 些 自 己 的 特殊 处 理 了 。 


1.2 ”Activity 的 启动 模式 


上 一 市 介绍 了 Activity 在 标准 情况 下 和 异常 情况 下 的 生命 周期 ， 我 
们 对 Activity 的 生命 周期 应 该 有 了 深入 的 了 解 。 除 了 Activity 的 生命 周 
期 外 ，Activity 的 局 动 模式 也 是 一 个 难点 ， 原 因 有 是 形形色色 的 局 动 模式 
和 标志 位 实在 是 太 容易 被 混 光 了， 但 古 Activity 作 为 四 大 组 件 之 首 ， 它 
的 的 确 确 非常 重要 ， 有 时候 为 了 满足 项 目的 特殊 需求 ， 束 必须 使 用 


Activity 的 局 动 模式 ， 所 以 我 们 必须 要 搞 清 楚 它 的 局 动 模 式 和 标志 位 ， 
本 六 性 全 I 人 六 


1.2.1 Activity 的 LaunchMode 


自 先 说 一 下 Activity 为 什么 需要 启动 模式 。 我 们 知道 ， 在 默认 情况 
下 ， 当 我 们 多 次 启动 同一 个 Activity 的 时 候 ， 系 统 会 创建 多 个 实例 并 把 
它们 一 一 放 入 任务 栈 中 ， 当 我 们 单 击 back 键 ， 会 发 现 这 些 Activity 会 一 
一 回 退 。 任 务 栈 是 一 种 “后 进 先 出 ”的 栈 结 构 ， 这 个 比较 好 理解 ， 每 按 
一 下 back 键 束 会 有 一 个 Activity 出 栈 ， 直 到 栈 空 为 止 ， 当 栈 中 无 任何 
Activity 的 时 候 ， 系 统 丈 会 回收 这 个 任务 栈 。 关 于 任务 栈 的 系统 工作 原 
理 ， 这 里 暂时 不 做 说 明 ， 在 后 续 章 节 会 专门 介绍 任务 栈 。 知 道 了 
Activity 的 默认 启动 模式 以 后 ， 我 们 可 能 束 会 发 现 一 个 问题 ， 多 次 启动 
同一 个 Activity， 系 统 重复 创建 多 个 实例 ， 这 样 不 是 很 傻 吗 ? 这 样 的 确 
有 点 傻 ，Android 在 设计 的 时 候 不 可 能 不 考虑 到 这 个 问题 ， 所 以 它 提 供 
了 局 动 模式 来 修改 系统 的 默认 行为 。 目 前 有 四 种 启动 模式 : standard ` 
singleTop、singleTask 和 singleInstance， 下 面 先 介绍 各 种 启动 模式 的 含 
X: 


(1) standard: 标准 模式 ， 这 也 是 系统 的 默认 模式 。 每 次 启动 一 
个 Activity 都 会 重新 创建 一 个 新 的 实例 ， 不 管 这 个 实例 是 否 已 经 存在 。 
被 创建 的 实例 的 生命 周期 符合 典型 情况 下 Activity 的 生命 周期 ， 如 上 市 
摘 述 ， 它 的 onCreate、onStart、onResume 都 会 被 调用 。 这 是 一 种 典型 
的 多 实例 实现 ， 一 个 任务 栈 中 可 以 有 多 个 实例 ， 每 个 实例 也 可 以 属于 
不 同 的 任务 栈 。 在 这 种 模式 下 ， 谁 局 动 了 这 个 Activity ， 那 么 这 个 
Activity 就 运行 在 启动 它 的 那个 Activity 所 在 的 栈 中 。 比 如 Activity AJA 


5) [ Activity B (B 是 标准 模式 ) ， 那 么 B 就 会 进入 到 A 所 在 的 栈 中 。 不 
知道 读者 是 否 注意 到 ， 当 我 们 用 ApplicationContext 去 启动 standard 模 式 
的 Activity 的 时 候 会 报错 ， 错 误 如 下 : 


E/AndroidRuntime(674): 
android.util.AndroidRuntimeException: Calling 
startActivity from outside of an Activity context requires the 


FLAG_ ACTIVITY_NEW_TASK flag. Is this really what you want? 


相信 这 句 话 读者 一 定 不 陌生 ， 这 是 因为 standard 模 式 的 Activity 默 
认 会 进入 局 动 它 的 Activity 所 属 的 任务 栈 中 ， 但 是 由 于 非 Activity 类 型 
的 Context (如 ApplicationContext) 并 没有 所 谓 的 任务 栈 ， 所 以 这 就 有 
问题 了。 解决 这 个 问题 的 方法 是 为 待 局 动 Activity 指定 
FLAG_ACTIVITY_NEW_TASK 标 记 位 ， 这 样 启 动 的 时 候 就 会 为 它 创 
建 一 个 新 的 任务 栈 ， 这 个 时 候 每 启动 Activity 实 际 上 是 以 singleTask 模 
式 局 动 的 ， 读 者 可 以 仔细 体会 。 


(2) singleTop: 栈 顶 复 用 模式 。 在 这 种 模式 下 ， 如 果 新 Activity 
己 经 位 于 任务 栈 的 栈 顶 ， 那 么 此 Activity 不 会 被 重新 创建 ， 同 时 它 的 
onNewIntent 方 法 会 被 回调 ， 通 过 此 方法 的 参数 我 们 可 以 取出 当前 请 求 
的 信息 。 需 要 注意 的 是 ， 这 个 Activity 的 onCreate、onStart 不 会 被 系统 
调用 ， 因 为 它 并 没有 发 生 改 变 。 如 果 新 Activity 的 实例 已 存在 但 不 是 位 
于 栈 顶 ， 那 么 新 Activity 仍 然 会 重新 重建 。 举 个 例子 ， 假 设 目前 栈 内 的 
情况 为 ABCD， 其 中 ABCD 为 四 个 Activity，A 位 于 栈 底 ，D 位 于 栈 顶 ， 
这 个 时 候 假设 要 再 次 启动 D， 如 果 D 的 启动 模式 为 singleTop， 那 么 栈 内 
的 情况 仍然 为 ABCD; 如 果 D 的 局 动 模式 为 standard， 那 么 由 于 D 被 重 
新 创建 ， 导 致 栈 内 的 情况 就 变 为 ABCDD 。 


(3) singleTask: 栈 内 复 用 模式 。 这 是 一 种 单 实例 模式 ， 在 这 种 
模式 下 ， 只 要 Activity 在 一 个 栈 中 存在 ， 那 么 多 次 启动 此 Activity 都 不 
会 重新 创建 实例 ， 和 singleTop 一 样 ， 系 统 也 会 回调 其 onNewIntent。 具 
体 一 点 ， 当 一 个 具有 singleTask 模 式 的 Activity 请 求 局 动 后 ， 比 如 
Activity A， 系 统 首先 会 寻找 是 否 存在 A 想 要 的 任务 栈 ， 如 采 不 存在 ， 
束 重 新 创建 一 个 任务 栈 ， 然 后 创建 A 的 实例 后 把 A 放 到 栈 中 。 如 有 果 存 在 
A 所 需 的 任务 栈 ， 这 时 要 看 A 是 否 在 栈 中 有 实例 存在 ， 如 有 果 有 实例 存 
在 ， 那 么 系统 就 会 把 A 调 到 栈 顶 并 调用 它 的 onNewIntent 方 法 ， 如 采 实 
例 不 存在 ， 束 创建 A 的 实例 并 把 A 压 入 栈 中 。 举 儿 个 例子 : 


。 比如 目前 任务 栈 S1 中 的 情况 为 ABC， 这 个 时 候 Activity D 以 
singleTask 模 式 请 求 局 动 ， 其 所 需要 的 任务 栈 为 922， 由 于 $2 和 D 的 
实例 均 不 存在 ， 所 以 系统 会 完 创 建 任务 栈 S2， 然 后 再 创建 DD 的 实 
例 并 将 其 入 栈 到 S2。 

男 外 一 种 情况 ， 假 设 D 所 需 的 任务 栈 为 S1， 其 他 情况 如 上 面 例子 1 
所 示 ， 那 么 由 于 S1 已 经 存在 ， 所 以 系统 会 直接 创建 D 的 实例 并 将 
其 入 栈 到 S1 。 

如 果 D 所 需 的 任务 栈 为 S1， 并 且 当 前 任务 栈 S1 的 情况 为 ADBC， 
根据 栈 内 复 用 的 原则 ， 此 时 D 不 会 重新 创建 ， 系 统 会 把 D 切 换 到 栈 
顶 并 调用 其 onNewIntent 方 法 ， 同 时 由 于 singleTask 默 认 有 具有 
clearTop 的 效果 ， 会 导致 栈 内 所 有 在 D 上 面 的 Activity 全 部 出 栈 ， 于 
是 最 终 S1 中 的 情况 为 AD。 这 一 点 比较 特殊 ， 在 后 面 还 会 对 此 种 情 
况 详 细 地 分 析 。 


通过 上 述 3 个 例子 ， 读 者 应 该 能 比较 清晰 地 理解 singleTask 的 含义 


(4) singleInstance: 单 实 例 模 式 。 这 是 一 种 加 强 的 singleTask 模 
式 ， 它 除了 具有 singleTask 模 式 的 所 有 特性 外 ， 还 加 强 了 一 点 ， 那 就 是 
具有 此 种 模式 的 Activity 只 能 单独 地 位 于 一 个 任务 栈 中 ， 换 名 话说， 比 
如 Activity A 是 singleInstance 模 式 ， 当 A 局 动 后 ， 系 统 会 为 它 创 建 一 个 
新 的 任务 栈 ， 然 后 A 独 目 在 这 个 新 的 任务 栈 中 ， 由 于 栈 内 复 用 的 特 
性 ， 后 续 的 请 求 均 不 会 创建 新 的 Activity， 除 非 这 个 独特 的 任务 栈 被 系 
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上 面 介 绍 了 几 种 局 动 模式 ， 这 里 需要 指出 一 种 情况 ， 我 们 假设 目 
前 有 2 个 任务 栈 ， 前 台 任 务 栈 的 情况 为 AB， 而 后 台 任 务 栈 的 情况 为 
CD， 这 里 假设 CD 的 启动 模式 均 为 singleTask。 现 在 请 求 启动 D， 那 么 
整个 后 台 任 务 栈 都 会 被 切换 到 前 台 ， 这 个 时 候 整个 后 退 列 表 变 成 了 
ABCD。 当 用 户 按 back 键 的 时 候 ， 列 表 中 的 Activity 会 一 一 出 栈 ， 如 图 
1-7 所 示 。 如果 不 是 请 求 启动 D 而 是 局 动 C， 那 么 情况 整 不 一 样 了 ， 请 
看 图 1-8， 具 体 原因 在 本 市 后 面 会 再 进行 详细 分 析 。 
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图 1-7 任务 栈 示例 1 
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图 1-8 ”任务 栈 示 例 2 


男 外 一 个 问题 是 ， 在 singleTask 启 动 模式 中 ， 多 次 提 到 某 个 
Activity 所 需 的 任务 栈 ， 什 么 是 Activity 所 需要 的 任务 栈 呢 ? 这 要 从 一 
个 参数 说 起 : TaskAffinity， 可 以 翻译 为 任务 相关 性 。 这 个 参数 标识 了 
一 个 Activity 所 需要 的 任务 栈 的 名 字 ， 默 认 情 况 下 ， 所 有 Activity 所 需 
的 任务 栈 的 名 字 为 应 用 的 包 名 。 当 然 ， 我 们 可 以 为 每 个 Activity 都 单独 
指定 TaskAffinity 属 性 ， 这 个 属性 值 必须 不 能 和 包 名 相同 ， 否 则 就 相当 
于 没有 指定 。TaskAffinity 属 性 主要 和 singleTask 启 动 模式 或 者 
allowTaskReparenting 属 性 配对 使 用 ， 在 其 他 情况 下 没有 意义 。 男 外 ， 


任务 栈 分 为 前 台 任 务 栈 和 后 全 任务 栈 ， 后 台 任 务 栈 中 的 Activity 位 于 和 暂 
停 状态 ， 用 户 可 以 通过 切换 将 后 台 任 务 栈 再 次 调 到 前 台 。 


当 TaskAffinity 和 singleTask 启 动 en 的 时 候 ， 它 是 具有 i 
模式 的 Activity 的 目前 任务 栈 的 名 字 ， 竺 局 动 的 Activity 会 运行 在 名 
和 TaskAffinity 相 同 的 任务 栈 中 。 
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当 TaskAffinity 和 allowTaskReparenting 结 合 的 时 候 ， 这 种 情况 比较 
复杂 ， 会 产生 特殊 的 效果 。 当 一 个 应 用 A 局 动 了 应 用 B 的 某 个 Activity 
后 ， 如 果 这 个 Activity 的 allowTaskReparenting 属 性 为 true 的 话 ， 那 么 当 
应 用 B 被 启动 后 ， 此 Activity 会 直接 从 应 用 A 的 任务 栈 转移 到 应 用 B 的 任 
务 栈 中 。 这 还 是 很 抽象 ， 再 具体 点 ， 比 如 现在 有 2 个 应 用 A 和 B，A 局 
动 了 B 的 一 个 Activity C， 然 后 按 Home 键 回 到 桌面 ， 然 后 再 单 击 B 的 桌 
面 图 标 ， 这 个 时 候 并 不 是 启动 了 B 的 主 Activity， 而 是 重新 显示 了 已 经 
被 应 用 A 局 动 的 Activity C， 或 者 说 ，C 从 A 的 任务 栈 转移 到 了 B 的 任务 
栈 中 。 可 以 这 么 理解 ， 由 于 A 局 动 JC， 这 个 时 候 C 只 能 运行 在 A 的 任 
务 栈 中 ， 但 是 C 属 于 B 应 用 ， 正 常情 况 下 ， 它 的 TaskAffinity 值 肯定 不 可 
能 和 A 的 任务 栈 相 同 (因为 包 名 不 同 ) 。 所 以 ， 当 B 被 启动 后 ，B 会 创 
建 目 己 的 任务 栈 ， 这 个 时 候 系统 发 现 C 原 本 所 想 要 的 任务 栈 已 经 被 创 
建 了 ， 所 以 就 把 C 从 A 的 任务 栈 中 转移 过 来 了 。 这 种 情况 读者 可 以 写 个 
例子 测试 一 下 ， 这 里 就 不 做 示例 了 。 


如 何 给 Activity 指 定 启动 模式 呢 ? 有 两 种 方法 ， 第 一 种 是 通过 
AndroidMenifest 为 Activity 指 定 启动 模式 ， 如 下 所 示 。 
<activity 


android:name="com.ryg.chapter_1.SecondActivity" 


android:configChanges="screenLayout" 


android: LaunchMode="singleTask" 


android: label="@string/app_name" /> 


Fi 种 情况 是 通过 在 Intent 中 设置 标志 位 来 为 Activity 指 定局 动 模 
EL: 


Intent intent = new Intent(); 
intent.setClass(MainActivity.this,SecondActivity.class); 
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 


startActivity(intent); 


这 两 种 方式 都 可 以 为 Activity 指 定 启 动 模式 ， 但 是 二 者 还 是 有 区 别 
的 。 首 先 ， 优 先 级 上 ， 第 二 种 方式 的 优先 级 要 高 于 第 一 种 ， 当 两 种 同 
时 存在 时 ， 以 第 二 种 方式 为 准 ; 其 次 ， 上 述 两 种 方式 在 限定 范围 上 有 
所 不 同 ， 比 如 ， 第 一 种 方式 无 法 直接 为 Activity 设 定 
FLAG_ACTIVITY_CLEAR_TOP 标 识 ， 而 第 二 种 方式 无 法 为 Activity 指 
定 singleInstance 模 式 。 


关于 Intent 中 为 Activity 指 定 的 各 种 标记 位 ， 中 会 继 
续 介 绍 。 下 面 通过 一 个 例子 来 体验 局 动 模式 的 使 用 效果 。 还 是 前 面 的 
例子 ， 这 里 我 们 把 MainActivity 的 启动 模式 设 为 a ， 然 后 重复 
启动 它 ， 看 看 是 否 会 重复 创建 ， 代 码 修改 如 下 : 


<activity 
android:name="com.ryg.chapter_1.MainActivity" 
android:configChanges="orientation|screenSize" 
android:label="@string/app_name" 


android:launchMode="singleTask" > 


根据 上 述 修 改 ， 我 们 做 如 下 操作 ， 连 续 单 击 三 次 按钮 局 动 3 次 
MainActivity， 算 上 原本 的 MainActvity 的 实例 ， 正 常情 况 下 ， 任 务 栈 中 


应 该 有 4 个 MainActivity 的 实例 ， 但 是 我 们 为 其 指定 了 singleTask 模 式 ， 
现在 来 看 一 看 到 确 有 何不 同 。 


执行 adb shell dumpsys activity 命 令 : 


ACTIVITY MANAGER ACTIVITIES (dumpsys activity activities) 
Main stack: 
TaskRecord{41350dc8 #9 A com.ryg.chapter_1} 
Intent { cmp=com.ryg.chapter_1/.MainActivity (has 
extras) } 
Hist #1: ActivityRecord{412cc188 
com.ryg.chapter_1/.MainActivity} 
Intent { act=android.intent.action.MAIN cat= 
[android.intent.category.LAUNCHER] flg=0x 
© cmp=com.ryg.chapter_1/.MainActivity bnds=[160, 235] 
[240,335] } 
ProcessRecord{411e6898 
634:com.ryg.chapter_1/10052} 
TaskRecord{4125abc8 #2 A com.android. launcher } 
Intent { act=android.intent.action.MAIN cat= 
[android.intent.category. 
HOME] f1g=0x10000000 
m.android.launcher/com.android.launcher2.Launcher } 
Hist #0: ActivityRecord{412381f8 
com.android.launcher/com. android. 
launcher2.Launcher } 


Intent { act=android.intent.action.MAIN cat= 


[android.intent. 
category.HOME] flg=0x1000 
p=com.android.launcher/com.android.launcher2.Launcher } 
ProcessRecord{411d24c8 
214:com.android. launcher/10013} 
Running activities (most recent first): 
TaskRecord{41350dc8 #9 A com.ryg.chapter_1} 
Run #1: ActivityRecord{412cc188 
com.ryg.chapter_1/.MainActivity) 
TaskRecord{4125abc8 #2 A com.android. launcher } 
Run #0: ActivityRecord{412381f8 
com.android.launcher/com. android. 
launcher2.Launcher } 
mResumedActivity: ActivityRecord{412cc188 
com.ryg.chapter_1/.MainActivity} 
mFocusedActivity: ActivityRecord{412cc188 
com.ryg.chapter_1/.MainActivity) 
Recent tasks: 
* Recent #0: TaskRecord{41350dc8 #9 A com.ryg.chapter_1} 
* Recent #1: TaskRecord{4125abc8 #2 A 
com.android. launcher} 
* Recent #2: TaskRecord{412b60a0 #5 A 
com.estrongs.android.pop.app. 


InstallMonitorActivity} 


从 上 面 导出 的 Activity 信 息 可 以 看 出 ， 尺 管 局 动 了 4 次 
MainActivity， 但 十 它 始 终 只 有 一 个 实例 在 任务 栈 中 ， 从 图 1-9 的 log 可 


以 看 出 ，Activity 的 确 没有 重新 创建 ， 只 是 暂停 了 一 下 ， 然 后 调用 了 
onNewlIntent， 接 着 调用 onResume 束 又 继续 了 。 


J 


Tag Text 

MainActivity onPause 

MainActivity onNewIntent, time=1422898165307 
MainActivity onResume 

MainActivity onPause 

MainActivity onNewIntent, time=1422898166173 
MainActivity onResume 

MainActivity onPause 

MainActivity onNewIntent, time=1422898167429 
MainActivity onResume 


sa ~ 
own 
own 
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图 1-9 AAR 


现在 我 们 去 掉 singleTask， 再 来 对 比 一 下 ， 还 是 同样 的 操作 ， 单 击 
三 次 按钮 启动 MainActivity 三 次 。 


执行 adb shell dumpsys activity 命 令 : 


803:com.ryg.chapter_1/10052) 
Hist #3: ActivityRecord{411f4b30 
com.ryg.chapter_1/.MainActivity) 
Intent { cmp=com.ryg.chapter_1/.MainActivity (has 
extras) } 
ProcessRecord{411e6898 
803:com.ryg.chapter_1/10052} 
Hist #2: ActivityRecord{411edcb8 
com.ryg.chapter_1/.MainActivity} 
Intent { cmp=com.ryg.chapter_1/.MainActivity (has 
extras) } 
ProcessRecord{411e6898 
803:com.ryg.chapter_1/10052} 
Hist #1: ActivityRecord{411e7588 
com.ryg.chapter_1/.MainActivity) 
Intent { act=android.intent.action.MAIN cat= 
[android.intent.category. 
LAUNCHER] flg=0x10 
© cmp=com.ryg.chapter_1/.MainActivity } 
ProcessRecord{411e6898 
803:com.ryg.chapter_1/10052} 
TaskRecord{4125abc8 #2 A com.android. launcher} 
Intent { act=android.intent.action.MAIN cat= 
[android.intent.category. 
HOME] flg=0x10000000 c 
m.android.launcher/com.android.launcher2.Launcher } 


Hist #0: ActivityRecord{412381f8 


com.android.launcher/com.android. 
launcher2.Launcher } 
Intent { act=android.intent.action.MAIN cat= 
[android.intent.cate- 
gory.HOME] flg=0x100000 
p=com.android.launcher/com.android.launcher2.Launcher } 
ProcessRecord{411d24c8 
214:com.android. launcher/10013} 
Running activities (most recent first): 
TaskRecord{41325370 #17 A com.ryg.chapter_1} 
Run #4: ActivityRecord{41236968 
com.ryg.chapter_1/.MainActivity) 
Run #3: ActivityRecord{411f4b30 
com.ryg.chapter_1/.MainActivity) 
Run #2: ActivityRecord{411edcb8 
com.ryg.chapter_1/.MainActivity) 
Run #1: ActivityRecord{411e7588 
com.ryg.chapter_1/.MainActivity) 
TaskRecord{4125abc8 #2 A com.android. launcher } 
Run #0: ActivityRecord{412381f8 
com.android.launcher/com. android. 
launcher2.Launcher } 
mResumedActivity: ActivityRecord{41236968 
com.ryg.chapter_1/.MainAc- 
tivity} 
mFocusedActivity: ActivityRecord{41236968 


com.ryg.chapter_1/.MainAc- 


上 面 的 导出 信息 很 多 ， 我 们 可 以 有 选择 地 看 ， 比 如 就 看 Running 
activities (most recent firsb 这 一 块 ， 如 下 所 示 。 


我 们 能 够 得 出 目前 总 共有 2 个 任务 栈 ， 前 人 台 任 务 栈 的 taskAffinity 值 
为 com.ryg. chapter 1， 它 里 面 有 4 个 Activity， 后 台 任 务 栈 的 taskAffinity 
(E Ncom.android.launcher, UE M4A14 Activity, XP Activity Be R 
面 。 通 过 这 种 方式 来 分 析 任务 栈 信息 就 清晰 多 了 。 


从 上 面 的 导出 信息 中 可 以 看 到 ， 在 任务 栈 中 有 4 个 MainActivity， 
这 也 就 验证 了 Activity 的 启动 模式 的 工作 方式 。 


上 有 述 四 种 启动 模式 ，standard 和 singleTop 都 比较 好 理解 ， 
singleInstance 由 于 其 特殊 性 也 好 理解 ， 但 是 关于 singleTask 有 一 种 情况 
需要 再 说 明 一 下 。 如 图 1-7 所 示 ， 如 果 在 Activity B 中 请 求 的 不 是 D 而 是 
C， 那 么 情况 如 何 呢 ?这 里 可 以 告诉 读者 的 是 ， 任 务 栈 列表 变 成 了 
ABC， 是 不 是 很 奇怪 呢 ? Activity D 被 直接 出 栈 了 。 下 面 我 们 再 用 实例 
验证 看 看 是 不 是 这 样 。 首 先 ， 还 是 使 用 上 面 的 代码 ， 但 是 我 们 做 一 下 
修改 : 


<activity 
android:name="com.ryg.chapter_1.MainActivity" 
android: configChanges="orientation|screenSize" 
android: Llabel="@string/app_name" 
android: LaunchMode="standard" > 
<intent-filter> 
<action 
android: name="android.intent.action.MAIN" /> 
<category 
android: name="android.intent.category.LAUNCHER" /> 
</intent-filter> 


</activity> 


<activity 
android:name="com.ryg.chapter_1.SecondActivity" 
android: configChanges="screenLayout" 
android: Llabel="@string/app_name" 
android: taskAffinity="com.ryg.taski" 
android: LaunchMode="singleTask" /> 

<activity 
android:name="com.ryg.chapter_1.ThirdActivity" 
android: configChanges="screenLayout" 
android: taskAffinity="com.ryg.taski" 
android: Llabel="@string/app_name" 


android: LlaunchMode="singleTask" /> 


我 们 将 SecondActivity 和 ThirdActivity 都 设 成 singleTask 并 指定 它们 
的 taskAffinity 属 性 为 “com.ryg.task1”， 注 意 这 个 taskAffinity 属 性 的 值 为 
字符 串 ， 且 中 间 必 须 含 有 包 名 分 隔 符 “.”。 然 后 做 如 下 操作 ， 在 
MainActivity 中 单 击 按钮 启动 SecondActivity， 在 SecondActivity 中 单 击 
按钮 启动 ThirdActivity ， 在 ThirdActivity 中 单 击 按钮 又 启动 
MainActivity， 最 后 再 在 MainActivity 中 单 击 按钮 启动 SecondActivity， 
现在 按 back 键 ， 然 后 看 到 的 是 哪个 Activity? SRSA NE 
有 点 措 不 到 头脑 了 ? 没关系 ， 接 下 来 我 们 分 析 这 个 问题 。 


目 和 完 ， 从 理论 上 分 析 这 个 问题 ， 先 假设 MainActivity 为 A， 
SecondActivity 为 B，ThirdActivity 为 C。 我 们 知道 A 为 standard 模 式 ， 按 
照 规定 ，A 的 taskAffinity 值 继承 目 Application AY taskAffinity , 而 
Application 默 认 taskAffinity 为 包 名 ， 所 以 A 的 taskAffinity 为 包 名 。 由 于 
我 们 在 XML 中 为 B 和 C 指 定 了 taskAffinity 和 启动 模式 ， 所 以 B 和 C 是 


singleTask 模 式 昌 有 相同 的 taskAffinity 值 “com.ryg.task1”。 A 启动 B 的 时 
候 ， 按 照 singleTask 的 规则 ， 这 个 时 候 需 要 为 B 重 新 创建 一 个 任务 
栈 “com.ryg.taskl”。B 再 启动 C， 按 照 sngleTask 的 规则 ， 由 于 C 所 需 的 
ESE (和 B 为 同一 任务 栈 ) 已 经 被 B 创 建 ， 所 以 无 须 再 创建 新 的 任务 
栈 ， 这 个 时 候 系统 只 是 创建 C 的 实例 后 将 C 入 栈 了 。 接 着 C 再 局 动 A，A 
是 standard 模 式 ， 所 以 系统 会 为 它 创建 一 个 新 的 实例 并 将 到 加 到 启动 它 
的 那个 Activity 的 任务 栈 ， 由 于 是 C 局 动 了 A， 所 以 A 会 进入 C 的 任务 栈 
中 并 位 于 栈 顶 。 这 个 时 候 已 经 有 两 个 任务 栈 了 ， 一 个 是 名 字 为 包 名 的 
任务 栈 ， 里 面 只 有 A， 男 一 个 是 名 字 为 “com.ryg.task1” 的 任务 栈 ， 里 面 
的 Activity 为 BCA。 接 下 来 ，A 再 启动 B， 由 于 B 是 singleTask，B 和 需要 回 
到 任务 栈 的 栈 顶 ， 由 于 栈 的 工作 模式 为 “后 进 先 出 ”，B 想 要 回 到 栈 
顶 ， 只 能 是 CA 出 栈 。 所 以 ， 到 这 里 就 很 好 理解 了 ， 如 有 果 再 按 back 键 ， 
B 束 出 栈 了 ，B 所 在 的 任务 栈 已 经 不 存在 了 ， 这 个 时 候 只 能 是 回 到 后 人 台 
任务 栈 并 把 A 显示 出 来 。 注 意 这 个 A 是 后 台 任 务 栈 的 A， 不 
是 “com.ryg.task1” 任 务 栈 的 A， 接 着 再 继续 back， 残 回 到 桌面 了 。 分 析 
到 这 里 ， 我 们 得 出 一 条 结论 ，singleTask 模 式 的 Activity 切 换 到 栈 顶 会 
导致 在 它 之 上 的 栈 内 的 Activity 出 栈 。 


接 痢 我 们 在 实践 中 再 次 验证 这 个 问题 ， 还 是 采用 dumpsys 命 令 。 
我 们 省 略 中 间 的 过 程 ， 直 接 看 C 局 动 A 的 那个 状态 ， 执 行 adb shell 


dumpsys activity 命 令 ， 日 志 如 下 : 


Running activities (most recent first): 
TaskRecord{4132bd90 #12 A com.ryg.task1) 
Run HA: ActivityRecord{4133fd18 
com.ryg.chapter_1/.MainActivity} 
Run #3: ActivityRecord{41349c58 


com.ryg.chapter_1/.ThirdActivity} 
Run #2: ActivityRecord{4132bab0 
com.ryg.chapter_1/.SecondActivity} 
TaskRecord{4125a008 #11 A com.ryg.chapter_1} 
Run #1: ActivityRecord{41328c60 
com.ryg.chapter_1/.MainActivity} 
TaskRecord{41256440 #2 A com.android. launcher} 
Run #0: ActivityRecord{41231d30 
com.android.launcher/com. android. launch 


er2.Launcher } 


可 以 清楚 地 看 到 有 2 个 任务 栈 ， 第 一 个 (com.ryg.chapter 1) A 
A， 第 二 个 (com.ryg.task1) 有 BCA， 就 如 同 我 们 上 面 分 析 的 那样 ， 然 
后 再 从 A 中 启动 B， 再 看 一 下 日 志 : 


Running activities (most recent first): 
TaskRecord{4132bd90 #12 A com.ryg.task1} 
Run #2: ActivityRecord{4132bab0 
com.ryg.chapter_1/.SecondActivity} 
TaskRecord{4125a008 #11 A com.ryg.chapter_1} 
Run #1: ActivityRecord{41328c60 
com.ryg.chapter_1/.MainActivity} 
TaskRecord{41256440 #2 A com.android. launcher} 
Run #0: ActivityRecord{41231d30 
com.android. launcher/com. android. launch 


er2.Launcher } 


可 以 发 现在 任务 栈 com.ryg.taskl 中 只 剩 人 B 了 ，C、A 都 已 经 出 栈 
了 ， 这 个 时 候 再 按 back 键 ， 任 务 栈 com.ryg.chapter_1 中 的 A 就 显示 出 来 
了 ， 如 有 果 再 back 束 回 到 曲面 了 。 分 析 到 这 里 ， 相 信 读 者 对 Activity 的 启 
动 模式 已 经 有 很 深入 的 理解 了 。 下 面 介 绍 Activity 中 常用 的 标志 位 。 


1.2.2 Activity 的 Flags 


Activity 的 Flags 有 很 多 ， 这 里 主要 分 析 一 些 比 较 常 用 的 标记 位 。 标 
记 位 的 作用 很 多 ， 有 的 标记 位 可 以 设 定 Activity 的 启动 模式 ， 比 如 
FLAG_ACTIVITY_NEW_TASK 和 FLAG_ACTIVITY_SINGLE_TOP 
等 ;还 有 的 标记 位 可 以 影响 Activity 的 运行 状态 ， 比 如 
FLAG_ACTIVITY_CLEAR_TOP 和 
FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 等 。 下 面 主要 介绍 几 
个 比较 常用 的 标记 位 ， 剩 下 的 标记 位 读者 可 以 查看 官方 文档 去 了 解 ， 
大 部 分 情况 下 ， 我 们 不 需要 为 Activity 指 定 标记 位 ， 因 此 ， 对 于 标记 位 
理解 即 可 。 在 使 用 标记 位 的 时 候 ， 要 注意 有 些 标记 位 是 系统 内 部 使 用 
的 ， 应 用 程序 不 需要 去 手动 设置 这 些 标记 位 以 防 出 现 问题 。 


FLAG_ACTIVITY_NEW_TASK 


这 个 标记 位 的 作用 是 为 Activity 指 定 “singleTask” 局 动 模式 ， 其 效果 
和 在 XML 中 指定 该 启动 模式 相同 。 


FLAG_ACTIVITY_SINGLE_TOP 


这 个 标记 位 的 作用 是 为 Activity 指 定 “singleTop” 启 动 模式 ， 其 效果 
和 在 XML 中 指定 该 启动 模式 相同 。 


FLAG_ACTIVITY_CLEAR_TOP 


具有 此 标记 位 的 Activity， 当 它 启 动 时 ， 在 同一 个 任务 栈 中 所 有 位 
于 它 上 面 的 Activity 都 要 出 栈 。 这 个 模式 一 般 需 要 和 
FLAG_ACTIVITY NEW_TASK 配 合 使 用 ， 在 这 种 情况 下 ， 被 启动 
Activity 的 实例 如 果 已 经 存在 ， 那 么 系统 就 会 调用 它 的 onNewIntent。 如 
果 被 启动 的 Activity 采 用 standard 模 式 启 动 ， 那 么 它 连 同 它 之 上 的 
Activity 都 要 出 栈 ， 系 统 会 创建 新 的 Activity 实 例 并 放 入 栈 顶 。 通 过 
1.2.1 节 中 的 分 析 可 以 知道 ，singleTask 启 动 模式 默认 就 具有 此 标记 位 的 
效果 。 


FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 


具有 这 个 标记 的 Activity 不 会 出 现在 历史 Activity 的 列表 中 ， 当 某 
些 情况 下 我 们 不 希望 用 户 通 过 历史 列表 回 到 我 们 的 Activity 的 时 候 这 个 
标记 比较 有 用 。 它 等 同 于 在 XML 中 指定 Activity 的 属性 


android:excludeFromRecents="true" ° 


1.3 ”IntentFilter 的 匹配 规则 


我 们 知道 ， 启 动 Activity 分 为 两 种 ， 显 式 调用 和 隐 式 调用 。 二 者 的 
区 别 这 里 束 不 多 说 了 ， 显 式 调用 需要 明确 地 指定 被 启动 对 象 的 组 件 信 
思 ， 包 括 包 名 和 类 名 ， 而 隐 式 调用 则 不 需要 明确 指定 组 件 信 息 。 原则 
上 一 个 Intent 不 应 该 既是 显 式 调用 又 是 隐 式 调用 ， 如 果 二 者 共存 的 话 以 
显 式 调 用 为 主 。 显 式 调 用 很 滑 单 ， 这 里 主要 介绍 一 下 隐 陈 调用 。 隐 式 
调用 需要 Intent 能 够 匹配 目标 组 件 的 IntentFilter 中 所 设置 的 过 滤 信 有 息 ， 


OO FR AN VE A 7c IE JA) HM Activity ° IntentFilter FAY Wt ie fa A 
action ` category ` data, He — IE AIM: 


<activity 

android:name="com.ryg.chapter_1.ThirdActivity" 

android: configChanges="screenLayout" 

android: label="@string/app_name" 

android: LaunchMode="singleTask" 

android: taskAffinity="com.ryg.taski"> 

<intent-filter> 
<action android:name="com.ryg.charpter_1.c"/> 
<action android:name="com.ryg.charpter_1.d"/> 
<category android:name="com.ryg.category.c"/> 
<category android:name="com.ryg.category.d"/> 

<category 
android: name="android.intent.category.DEFAULT"/> 

<data android:mimeType="text/plain"/> 

</intent-filter> 


</activity> 


为 了 匹配 过 滤 列 表 ， 需 要 同时 匹配 过 滤 列 表 中 的 action、 
category、data 人 信息， 否则 匹配 失败 。 一 个 过 小 列表 中 的 action、 
category 和 data 可 以 有 多 个 ， 所 有 的 action 、category、data 分 别 构成 不 
同类 别 ， 同 一 类 别 的 信息 共同 约束 当前 类 别 的 匹配 过 程 。 只 有 一 个 
Intent 同 时 匹配 action 类 别 、category 类 别 、data 类 别 才 算 完 全 匹配 ， 

有 完全 匹配 才能 成 功 局 动 目标 Activity。 另 外 一 ee 


以 有 多 个 intent-filter， 一 个 Intent 只 要 能 匹配 任何 一 组 intent-filter 即 可 成 
功 启动 对 应 的 Activity， 如 下 所 示 。 


</intent-filter> 


</activity> 
下 面 详细 分 析 各 种 属性 的 匹配 规则 。 
1. action 的 匹配 规则 


action 是 一 个 字符 串 ， 系 统 预定 义 了 一 些 action， 同 时 我 们 也 可 以 
在 应 用 中 定义 目 己 的 action。action 的 匹配 规则 是 Pntent 中 的 action 必 须 
能 够 和 过 滤 规 则 中 的 action 匹 配 ， 这 里 说 的 匹配 是 指 action 的 字符 串 值 
完全 一 样 。 一 个 过 滤 规 则 中 可 以 有 多 个 action， 那 么 只 要 Intent 中 的 
action 能 够 和 过 小 规则 中 的 任何 一 个 action 相 同 即 可 匹配 成 功 。 和 针对 上 
面 的 过 滤 规 则 ， 只 要 我 们 的 Intent 中 action 值 为 “com.ryg.charpter_1.c” 或 
者 “com.ryg.charpter_1.d” 都 能 成 功 匹 配 。 需 要 注意 的 是 ，Intent 中 如 果 
没有 指定 action， 那 么 匹配 失败 。 总 结 一 下 ，action 的 匹配 要 求 Intent 中 
的 action 存 在 且 必 须 和 过 滤 规 则 中 的 其 中 一 个 action 相 同 ， 这 里 需要 注 
意 它 和 category 匹 配 规则 的 不 同 。 另 外 ，action 区 分 大 小 写 ， 大 小 写 不 
同 字 符 串 相同 的 action 会 匹配 失败 。 


2. category 的 匹配 规则 


category 是 一 个 字符 串 ， 系 统 预定 义 了 一 些 category， 同 时 我 们 也 
可 以 在 应 用 中 定义 目 己 的 category 。category 的 匹配 规则 和 action 不 同 ， 
它 要 求 Intent 中 如 果 含 有 category， 那 么 所 有 的 category 都 必须 和 过 滤 规 
则 中 的 其 中 一 个 category 相 同 。 换 句 话说 ，Intent 中 如 果 出 现 了 
category， 不 管 有 几 个 category， 对 于 每 个 category 来 说 ， 它 必须 是 过 滤 
规则 中 已 经 定义 了 的 category。 当 然 ，Intent 中 可 以 没有 category， 如 果 
没有 category 的 话 ， 按 照 上 面 的 描述 ， 这 个 Pntent 仍 然 可 以 匹配 成 功 。 


这 里 要 注意 下 它 和 action 匹 配 过 程 的 不 同 ，action 是 要 求 Intent 中 必须 有 
一 个 action 且 必须 能 够 和 过 滤 规 则 中 的 某 个 action 相 同 ， 而 category 要 求 
Intent 可 以 没有 category， 但 是 如 果 你 一 旦 有 category， 不 管 有 几 个 ， 
个 都 要 能 够 和 过 滤 规 则 中 的 任何 一 个 category 相 同 。 为 了 匹配 前 面 的 过 
滤 规 则 中 的 category ， 我 们 可 以 写 出 下 面 的 Intent，intent.addcategory 
(“com.ryg.category.c”) #4 Intent. addcategory (“com.ryg.category.d”) J} By 
者 不 设置 category。 为 什么 不 设置 category 也 可 以 匹配 呢 ? 原因 是 系统 
在 调用 startActivity 或 者 startActivityForResult 的 时 候 会 默认 为 Intent 加 
上 “android.intent. category.DEFAULT” 这 个 category， 所 以 这 个 category 
束 可 以 匹配 前 面 的 过 滤 规 则 中 的 第 三 个 category。 同 时 ， 为 了 我 们 的 
activity 能 够 撑 收 隐 式 调用 ， 束 必须 在 intent-filter 中 指 
定 “android.intent.category.DEFAULT” 这 个 category， 原 因 刚 才 已 经 说 明 
了 o 


3. data 的 匹配 规则 


data 的 匹配 规则 和 action 类 似 ， 如 果 过 滤 规 则 中 定义 了 data， 那 么 
Intent 中 必须 也 要 定义 可 匹配 的 data。 在 介绍 data 的 匹配 规则 之 前 ， 我 
们 需要 先 了 解 一 下 data 的 结构 ， 因 为 data 和 稍微 有 些 复杂 。 


data 的 语法 如 下 所 示 。 


<data android:scheme="string" 
android:host="string" 
android:port="string" 
android:path="string" 


android:pathPattern="string" 


android:pathPrefix="string" 


android:mimeType="string" /> 


data 由 两 部 分 组 成 ，mimeType 和 URI。mimeType 指 媒体 类 型 ， 比 
如 image/jpeg、 audio/mpeg4-generic 和 video/* 等 ， 可 以 表示 图 片 、 文 
本 、 视 频 等 不 同 的 媒体 格式 ， 而 URI 中 包含 的 数据 就 比较 多 了 ， 下 面 
是 URI 的 结构 : 


<scheme>://<host>:<port>/[<path>|<pathPrefix> | 


<pathPattern>] 


7k FEE LS Pa) la A IE 


content://com.example.project:200/folder/subfolder/etc 


http://www.baidu.com:80/search/info 
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不 过 下 面 还 是 要 介绍 一 下 每 个 数据 的 含义 。 


Scheme: URI 的 模式 ， 比 如 http、file、content 等 ， 如 果 URI 中 没有 
指定 scheme， 那 么 整个 URI 的 其 他 参数 无 效 ， 这 也 意味 着 URI 是 无 效 
时 。 


Host: URI 的 主机 和 名， 比如 www.baidu.com， 如 果 host 未 指定 ， 那 
么 整个 URI 中 的 其 他 参数 无 效 ， 这 也 意味 着 URI 是 无 效 的 。 


Port: URI 中 的 端口 号 ， 比 如 80， 仅 当 URI 中 指定 了 scheme 和 host 
参数 的 时 候 port 参 数 才 是 有 意义 的 。 


Path > pathPatternXIpathPrefix: 这 三 个 参数 表述 路 径 信息 ， 其 中 
path 表 示 完 整 的 路 径 信息 ; pathPattern 也 表示 完整 的 路 径 信 息 ， 但 是 它 
里 面 可 以 包含 通配符 “*”,“*#” 表 示 0 个 或 多 个 任意 字符 ， 需 要 注意 的 
是 ， 由 于 正则 表达 式 的 规范 ， 如 果 想 表示 真实 的 字符 串 ， 那 么 “*” 要 写 
EA, WEE RAN; pathPrefix 表 示 路 径 的 前 级 信息 。 


介绍 完 data 的 数据 格式 后 ， 我 们 要 说 一 下 data 的 匹配 规则 了 。 前 面 
说 到 ，data 的 匹配 规则 和 action 类 似 ， 它 也 要 求 Intent 中 必须 含有 data 数 
据 ， 并 且 data 数 据 能 够 完全 匹配 过 滤 规 则 中 的 某 一 个 data. 这 里 的 完全 
匹配 是 指 过 滤 规 则 中 出 现 的 data 部 分 也 出 现在 了 Intent 中 的 data 中 。 下 
面 分 情况 说 明 。 


(1) 如 下 过 滤 规 则 : 


<intent-filter> 


<data android:mimeType="image/*" /> 


</intent-filter> 


这 种 规则 指定 了 媒体 类 型 为 所 有 类 型 的 图 片 ， 那 么 Intent 中 的 
mimeType 属 性 必须 为 “image/*” 才 能 匹配 ， 这 种 情况 下 虽然 过 滤 规 则 没 
有 指定 URI， 但 是 却 有 默认 值 ，URI 的 默认 值 为 content 和 file。 世 就 是 
说 ， 虽 然 没 有 指定 URI， 但 是 Intent 中 的 URI 部 分 的 schema 必 须 为 
content 或 者 file 才 能 匹配 ， 这 点 是 需要 尤其 注意 的 。 为 了 匹配 (1) 中 
规则 ， 我 们 可 以 写 出 如 下 示例 : 


intent.setDataAndType(Uri.parse("file://abc"),"image/png") ° 


另外 ， 如 有 果 要 为 Intent 指 定 完 整 的 data， 必 须要 调用 
setDataAndType 方 法 ， 不 能 先 调用 setData 再 调用 setType， 因 为 这 两 个 
方法 彼此 会 清除 对 方 的 值 ， 这 个 看 源码 就 很 容易 理解 ， 比 如 setData: 


public Intent setData(Uri data) { 
mData = data; 
mType = null; 
return this; 


} 


可 以 发 现 ，setData 会 把 mimeType 置 为 null， 同 理 setType 也 会 把 
URI 置 为 null ° 


(2) 如 下 过 滤 规 则 : 


<intent-filter> 
<data android:mimeType="video/mpeg" 
android:scheme="http" ... /> 
<data android:mimeType="audio/mpeg" 


android:scheme="http" ... /> 


</intent-filter> 


这 种 规则 指定 了 两 组 data 规 则 ， 且 每 个 data 都 指定 了 完整 的 属性 
值 ， 既 有 URI 又 有 mimeType。 为 了 匹配 (2) 中 规则 ， 我 们 可 以 写 出 如 
下 示例 : 


intent.setDataAndType(Uri.parse("http://abc"),"video/mpeg") 


set 
mt 


通过 上 面 两 个 示例 ， 读 者 应 该 已 经 明白 了 data 的 匹配 规则 ， 关 于 
data 还 有 一 个 特殊 情况 需要 说 明 下 ， 这 也 是 它 和 action 不 同 的 地 方 ， 如 
下 两 种 特殊 的 写法 ， 它 们 的 作用 是 一 样 的 : 


到 这 里 我 们 已 经 把 IntentFilter 的 过 滤 规 则 都 讲解 了 一 过， 还 记得 本 
节 前 面 给 出 的 一 个 intent-filter 的 示例 吗 ? 现在 我 们 给 出 完全 匹配 它 的 


Intent: 


intent.setDataAndType(Uri.parse("file://abc"),"text/plain"); 


startActivity(intent); 


还 记得 URI 的 schema 是 有 默认 值 的 吗 ? 如 果 把 上 面 的 
intent.setDataAndType (Uri.parse("file://abc"),"text/plain") 这 fJ 改 成 
intent.setDataAndType(Uri.parse("http://abc"),"text/plain"), FT FF Activity 
的 时 候 就 会 报错 ， 提 示 无 法 找到 Activity， 如 图 1-10 所 示 。 另 外 一 点 ， 
Intent-filter 的 匹配 规则 对 于 Service 和 BroadcastReceiver 也 是 同样 的 道 
理 ， 不 过 系统 对 于 Service 的 建议 是 尽量 使 用 显 式 调用 方式 来 启动 服 


务 。 


图 1-10 AZAR 


最 后 ， 当 我 们 通过 隐 式 方式 局 动 一 个 Activity 的 上 时候， 可 以 做 一 下 
判断 ， 看 是 否 有 Activity 能 够 匹配 我 们 的 隐 式 Intent， 如 果 不 做 判断 就 
有 可 能 出 现 上 述 的 错误 了 。 判 断 方法 有 两 种 : 采用 PackageManager 的 
resolveActivity 方 法 或 者 Intent 的 resolveActivity 方 法 ， 如 果 它 们 找 不 到 
匹配 的 Activity 束 会 返回 nul， 我 们 通过 判断 返回 值 束 可 以 规避 上 壕 错 
误 了 。 另 外 ，PackageManager 还 提供 了 queryIntentActivities 方 法 ， 这 个 
方法 和 resolveActivity 方 法 不 同 的 是 : 它 不 是 返回 最 佳 匹 配 的 Activity 信 
息 而 是 返回 所 有 成 功 匹 配 的 Activity 人 信息 。 我 们 看 一 下 
queryIntentActivities 和 resolveActivity 的 方法 原型 : 


public abstract List<ResolveInfo> 
queryIntentActivities(Intent intent, int 
flags); 
public abstract ResolveInfo resolveActivity(Intent 


intent,int flags); 


上 述 两 个 方法 的 第 一 个 参数 比较 好 理解 ， 第 二 个 参数 需要 注意 ， 

我 们 要 使 用 MATCH_DEFAULT_ONLY 这 个 标记 位 ， 这 个 标记 位 的 含 

是 仅仅 匹配 那些 在 intent-filtter 中 声明 了 <category 
android:name="android.intent.category.DEFAULT"/> 这 个 category 的 
Activity。 使 用 这 个 标记 位 的 意义 在 于 ， 只 要 上 述 两 个 方法 不 返回 
nul， 那 么 startActivity 一 定 可 以 成 功 。 如 果 不 用 这 个 标记 位 ， 残 可 以 
把 intent-filter 中 category 不 含 DEFAULT 的 那些 Activity 给 匹配 出 来 ， 从 
而 导致 startActivity 可 能 失败 。 因 为 不 含有 DEFAULT 这 个 category 的 
Activity 是 无 法 接收 隐 式 Intent 的 。 在 action 和 category 中 ， 有 一 类 action 


和 category 比 较 重要 ， 它 们 是 : 


<action android:name="android.intent.action.MAIN" /> 
<category android:name="android.intent.category.LAUNCHER" 


/> 


二 者 共同 作用 是 用 来 标明 这 是 一 个 入 口 Activity 并 且 会 出 现在 系 
少 了 任何 一 个 都 没有 实际 意义 ， 也 无 法 出 现在 系统 
WMAP, HMEZER—- AA eo Ab, EM Service 和 
BroadcastReceiver，PackageManager 同 样 提供 了 类 似 的 方法 去 获取 成 功 
匹配 的 组 件 信息 。 


22% IPC 机 制 


本 章 主要 讲解 Android 中 的 IPC 机 制 。 首 先 介绍 Android 中 的 多 进程 
概念 以 及 多 进程 开发 模式 中 第 见 的 注意 事项 ， 接 着 介绍 Android 中 的 序 
列 化 机 制 和 Binder ， 然 后 详细 介绍 Bundle、 文 件 共享 、AIDL > 
Messenger、ContentProvider 和 Socket 等 进程 间 通 信 的 方式 。 为 了 更 好 
地 使 用 AIDL 来 进行 进程 间 通 信 ， 本 章 还 引入 了 Binder 和 连接 池 的 概念 。 
最 后 ， 本 章 讲解 各 种 进程 间 通 信 方 式 的 优 缺 点 和 适用 场景 。 通 过 本 
划 ， 可 以 让 读者 对 Android 中 的 IPC 机 制 和 多 进程 开发 模式 有 深入 的 理 
解 。 


2.1 Android IPC 人 简介 


IPC 是 Inter-Process Communication 的 缩写 ， 含 义 为 进程 间 通 信 或 者 
跨 进 程 通 信 ， 是 指 两 个 进程 之 间 进 行 数据 交换 的 过 程 。 说 起 进程 间 通 
信 ， 我 们 首先 要 理解 什么 是 进程 ， 什 么 是 线程 ， 进 程 和 线程 是 截然 不 
同 的 概念 。 按 照 操 作 系 统 中 的 描述 ， 线 程 是 CPU 调度 的 最 小 单元 ， 同 
时 线程 是 一 种 有 限 的 系统 资源 。 而 进程 一 般 指 一 个 执行 单元 ， 在 PC 和 
移动 设备 上 指 一 个 程序 或 者 一 个 应 用 。 一 个 进程 可 以 包含 多 个 线程 ， 
因此 进程 和 线程 是 包含 与 被 包含 的 关系 。 最 简单 的 情况 下 ， 一 个 进程 
中 可 以 只 有 一 个 线程 ， 即 主线 程 ， 在 Android 里 面 主线 程 也 叫 UI 线 程 ， 
在 UI 线程 里 才能 操作 界面 元 素 。 很 多 时 候 ， 一 个 进程 中 需要 执行 大 量 
耗 时 的 任务 ， 如 果 这 些 任务 放 在 主线 程 中 去 执行 就 会 造成 界面 无 法 啊 
应 ， 严 重 影响 用 户 体 验 ， 这 种 情况 在 PC 系统 和 移动 系统 中 都 存在 ， 在 


Android 中 有 一 个 特殊 的 名 字 叫 做 ANR ( Application Not 
Responding) ， 即 应 用 无 啊 应 。 解 决 这 个 问题 束 需 要 用 到 线程 ， 把 一 
些 耗 时 的 任务 放 在 线程 中 即 可 。 


IPC 不 是 Android 中 所 独 有 的 ， 任 何 一 个 操作 系统 都 需要 有 相应 的 
IPC 机 制 ， 比 如 Windows 上 可 以 通过 剪贴 板 、 管 道 和 邮 覃 等 来 进行 进程 
间 通 信 ; Linux 上 可 以 通过 命名 管道 、 共 享 内 容 、 信 号 量 等 来 进 行进 程 
间 通 信 。 可 以 看 到 不 同 的 操作 系统 平台 有 着 不 同 的 进程 则 通信 方式 ,， 
对 于 Android 来 说 ， 它 是 一 种 基于 Linux 内 核 的 移动 操作 系统 ， 它 的 进 
程 间 通信 方式 并 不 能 完全 继承 目 Linux， 相 反 ， 它 有 目 己 的 进程 间 通 信 
方式 。 在 Android 中 最 有 特色 的 进程 间 通 信 方 式 隐 是 Binder 了， 通过 
Binder 可 以 轻松 地 实现 进程 间 通 信 。 除 了 Binder ，Android 还 文 持 
Socket， 通 过 Socket 也 可 以 实现 任意 两 个 终端 之 间 的 通信 ， 当 然 同 一 个 
设备 上 的 两 个 进程 通过 Socket 通 信 有 自 然 也 是 可 以 的 。 


说 到 IPC 的 使 用 场景 台 必 须 提 到 多 进程 ， 只 有 面 对 多 进程 这 种 场 
景 下 ， 才 需要 考虑 进程 间 通 信 。 这 个 是 很 好 理解 的 ， 如 果 只 有 一 个 进 
程 在 运行 ， 义 何 谈 多 进程 呢 ? 多 进程 的 情况 分 为 两 种 。 第 一 种 情况 是 
一 个 应 用 因为 某 些 原因 目 喘 需要 来 用 多 进程 模式 来 实现 ， 至 于 原因 ， 
可 能 有 很 多 ， 比 如 有 些 模块 由 于 特殊 原因 需要 运行 在 单独 的 进程 中 ， 
又 或 者 为 了 加 大 一 个 应 用 可 使 用 的 内 存 所 以 需要 通过 多 进程 来 获取 多 
份 内 存 空间 。Android 对 单个 应 用 所 使 用 的 最 大 内 存 做 了 限制 ， 早 期 的 
一 些 版 本 可 能 是 16MB ， 不 同 设备 有 不 同 的 大 小 。 另 一 种 情况 是 当前 
应 用 需要 问 其 他 应 用 获取 数据 ， 由 于 是 两 个 应 用 ， 所 以 必须 采用 路 进 
程 的 方式 来 获取 所 需 的 数据 ， 甚 至 我 们 通过 系统 提供 的 
ContentProvider 去 查询 数据 的 时 候 ， 其 实 也 是 一 种 进程 间 通 信 ， 只 不 
过 通信 细 市 被 系统 内 部 屏蔽 了 ， 我 们 无 法 感知 而 已 。 后 续 章 证 会 详细 


介绍 ContentProvider 的 底层 实现 ， 这 里 就 先 不 做 详细 介绍 了 。 总 之 ， 
不 管 由 于 何 种 原因 ， 我 们 采用 了 多 进程 的 设计 方法 ， 那 么 应 用 中 就 必 
须 妥 善 地 处 理 进 程 间 通信 的 各 种 问题 。 


2.2 ” Android 中 的 多 进程 模式 


在 正式 介绍 进程 间 通 信之 前 ， 我 们 必须 先 要 理解 Android 中 的 多 进 
程 模式 。 通 过 给 四 大 组 件 指定 android:process 属 性 ， 我 们 可 以 轻易 地 开 
局 多 进程 模式 ， 这 看 起 来 很 简单 ， 但 是 实际 使 用 过 程 中 却 暗藏 杀机 ， 
多 进程 远 远 没有 我 们 想 的 那么 简单 ， 有 时 候 我 们 通过 多 进程 得 到 的 好 
处 甚至 都 不 足以 弥补 使 用 多 进程 所 带 来 的 代码 层面 的 负面 影响 。 下 面 


会 评 细 分 析 这 些 问题 。 


2.2.1 开启 多 进程 模式 


正常 情况 下 ， 在 Android 中 多 进程 是 指 一 个 应 用 中 存在 多 个 进程 的 
情况 ， 因 此 这 里 不 讨论 两 个 应 用 之 间 的 多 进程 情况 。 首 先 ， 在 Android 
中 使 用 多 进程 只 有 一 种 方法 ， 那 就 是 给 四 大 组 件 (Activity * Service * 
Receiver > ContentProvider) 在 AndroidMenifest 中 指定 android:process 属 
性 ， 除 此 之 外 没有 其 他 办 法 ， 也 就 是 说 我 们 无 法 给 一 个 线程 或 者 一 个 
实体 类 指定 其 运行 时 所 在 的 进程 。 其 实 还 有 另 一 种 非常 规 的 多 进程 方 
法 ， 那 就 是 通过 JNI 在 native 层 去 fork 一 个 新 的 进程 ， 但 是 这 种 方法 属 
于 特殊 情况 ， 也 不 是 常用 的 创建 多 进程 的 方式 ， 因 此 我 们 暂时 不 考虑 
这 种 方式 。 下 面 是 一 个 示例 ， 摘 述 了 如 何在 Android 中 创建 多 进程 : 


<activity 
android:name="com.ryg.chapter_2.MainActivity" 
android:configChanges="orientation|screenSize" 
android:label="@string/app_name" 
android:launchMode="standard" > 
<intent-filter> 

<action 
android:name="android.intent.action.MAIN" /> 
<category 
android:name="android.intent.category.LAUNCHER" /> 

</intent-filter> 

</activity 

<activity 
android:name="com.ryg.chapter_2.SecondActivity" 
android:configChanges="screenLayout" 
android:label="@string/app_name" 
android:process=":remote" /> 

<activity 
android:name="com.ryg.chapter_2.ThirdActivity" 
android:configChanges="screenLayout" 
android: label="@string/app_name" 


android: process="com.ryg.chapter_2.remote" /> 


上 面 的 示例 分 别 为 SecondActivity 和 ThirdActivity 指 定 了 process 属 
性 ， 并 且 它 们 的 属性 值 不 同 ， 这 意味 着 当前 应 用 叉 增 加 了 两 个 新 进 
程 。 假 设 当 前 应 用 的 包 名 为 “com.ryg.chapter_2”， 当 SecondActivity 局 
DH, 系统 会 为 它 创 建 一 个 单独 的 进程 ， 进 程 名 


J “com.ryg.chapter_2: remote”; 当 ThirdActivity 局 动 时 ， 系 统 也 会 为 
它 创 建 一 个 单独 的 进程 ， 进 程 名 为 “com.ryg.chapter_2.remote”。 同时 入 
口 Activity 是 MainActivity， 没 有 为 它 指定 process 属 性 ， 那 么 它 运 行 在 


默认 进程 中 ， 默 认 进 程 的 进程 名 是 包 和 名。 下 面 我 们 运行 一 下 看 看 效 


果 ， 如 图 2-1 所 示 。 进 程 列 表 末 尾 存 在 3 个 进程 ， 进 程 id 分 别 为 645、 
659、672， 这 说 明 我 们 的 应 用 成 功 地 使 用 了 多 进程 技术 ， 十 不 是 很 商 


FANE? 这 只 十 开始 ， 实 际 使 用 中 多 进程 是 有 很 多 问题 需要 处理 的 。 


39 avd4.0.3 [emulator-5554] 
system_process 
com.android.systemui 
com.android.inputmethod.latin 
com.android.phone 
com.android.launcher 
com.android.settings 
android.process.acore 
com.android.calendar 
com.android.deskclock 
com.android.providers.calendar 
com.android.defcontainer 
android.process.media 
com.android.exchange 
com.android.email 
com.android.mms 
com.svox.pico 
com.estrongs.android.pop 
com.android.quicksearchbox 
com.android.keychain 
com.ryg.chapter_2 


com.ryg.chapter_2:remote 


com.ryg.chapter_2.remote 


Online 
77 
169 
187 
200 
214 
241 
263 
309 
349 
363 
393 
421 
440 
454 
476 
526 
539 
553 


645 


图 2-1 系统 进程 列表 


avd4.0.3 
8600 
8601 
8602 
8603 
8604 
8605 
8606 
8607 
8610 
8612 
8615 
8618 
8619 
8622 
8623 
8625 
8628 
8629 
8633 
8632 
8634 
8635 


ER T Eclipse DDMS MUA F EAHA E, Bay AA shed RE 
A, MH: adb shell ps 或 者 adb shell ps | grep com.ryg.chapter_2 ° 4 
FF com.ryg.chapter 2 是 包 名 ， 如 图 2-2 所 示 ， 通 过 ps 命令 也 可 以 查看 一 
个 包 名 中 当前 所 存在 的 进程 信息 。 


图 2-2 ”通过 ps 命令 来 查看 进程 信息 


不 知道 读者 朋友 有 没有 注意 到 ，SecondActivity 和 ThirdActivity 的 
android:process/% PE 74117 “remote” A] “com.ryg.chapter_2.remote”, Ab 

这 两 种 方式 有 区 别 吗 ? 其 实 是 有 区 别 的 ， 区 别 有 了 两 方面: a 
网 “2 的 含义 是 指 要 在 当前 的 进程 名 前 面 附加 上 当前 的 包 名 ， 这 是 一 
种 简写 的 方法 ， 对 于 SecondActivity 来 说 ， 它 完整 的 进程 名 为 
com.ryg.chapter_2:remote， 这 一 点 通过 图 2-1 和 2-2 中 的 进程 信息 也 能 
出 来 ， 而 对 于 ThirdActivity 中 的 声明 方式 ， 它 是 一 种 完整 的 命名 方式 ， 
不 会 附加 包 名 信息 ; 其 次 ， 进 程 名 以 “:” 开 头 的 进程 属于 当前 应 用 的 私 
有 进程 ， 其 他 应 用 的 组 件 不 可 以 和 它 跑 在 同一 个 进程 中 ， 而 进程 名 不 
以 “:” 开 头 的 进程 属于 全 局 进程 ， 其 他 应 用 通过 ShareUID 方 式 可 以 和 它 
跑 在 同一 个 进程 中 。 


我 们 知道 Android 系 统 会 为 每 个 应 用 分 配 一 个 唯一 的 UID， 具 有 相 
同 UID 的 应 用 才能 共 至 数据 。 这 里 要 说 明 的 是 ， 两 个 应 用 通过 
ShareUID 跪 在 同一 个 进程 中 十 有 要 求 的 ， 需 要 这 两 个 应 用 有 相同 的 
ShareUID 并 且 签 名 相同 才 可 以 。 在 这 种 情况 下 ， 它 们 可 以 互相 访问 对 
方 的 私有 数据 ， 比 如 data 目 未 、 组 件 信息 等 ， 不 管 它 们 是 否 跑 在 同一 
个 进程 中 。 当 然 如 有 果 它 们 跑 在 同一 个 进程 中 ， 那 么 除了 能 共 至 data 目 


录 、 组 件 信息 ， 还 可 以 共 至 内 存 数 据 ， 或 者 说 它们 看 起 来 束 像 古 一 个 
应 用 的 两 个 部 分 。 


2.2.2 ”多 进程 模式 的 运行 机 制 


如 果 用 一 句 话 来 形容 多 进程 ， 那 笔者 只 能 这 样 说 : “ 当 应 用 开局 了 
多 进程 以 后 ， 各 种 奇怪 的 现象 都 出 现 了 ”。 为 什么 这 么 说 呢 ? 这 是 有 原 
因 的 。 大 部 分 人 都 认为 开局 多 进程 是 很 徐 单 的 事情 ， 只 需要 给 四 大 组 
件 指定 android:process 属 性 即 可 。 比 如 说 在 实际 的 产品 开发 中 ， 可 能 会 
有 多 进程 的 需求 ， 需 要 把 某 些 组 件 放 在 单独 的 进程 中 去 运行 ， 很 多 人 
都 会 觉得 这 不 很 简单 吗 ? 然后 迅速 地 给 那些 组 件 指定 了 android:process 
属性 ， 然 后 编译 运行 ， 发 现 “ 正 常 地 运行 起 来 了 ”。 这 里 笔者 想 说 的 
是 ， 那 是 真 的 正常 地 运行 起 来 了 吗 ? 现在 移 不 置 可 否 ， 下 面 先 给 举 个 
例子 ， 然 后 引入 本 节 的 话题 。 还 是 本 章 刚 开始 说 的 那个 例子 ， 其 中 
SecondActivity 通 过 指定 android:process 属 性 从 而 使 其 运行 在 一 个 独立 
的 进程 中 ， 这 里 做 了 一 些 改 动 ， 我 们 新 建 了 一 个 类 ， 叫 做 
UserManager， 这 个 类 中 有 一 个 public 的 静态 成 员 变量 ， 如 下 所 示 。 


public class UserManager { 
public static int SUserId = 1; 


} 
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2， 打 印 出 这 个 静态 变量 的 值 后 再 启动 SecondActivity , TE 
SecondActivity 中 我 们 再 打印 一 下 SUserId 的 值 。 按 照 正 党 的 逻辑 ， 静 态 
变量 是 可 以 在 所 有 的 地 方 共 享 的 ， 并 旦 一 处 有 修改 处 处 都 会 同步 ， 
2-3 是 运行 时 所 打印 的 日 志 ， 我 们 看 一 下 结果 如 何 。 


Level PD TID Application Tag Text 
686 686 com.ryg.chapter 2 MainActivity UserManage. sUserId=2 


com.ryg.chapter_2:remote SecondActivity onCreate 


rea 
2 com.ryg.chapter_2:remote SecondActivity UserManage.sUserId=1 


图 2-3 ”系统 日 志 


看 了 图 2-3 中 的 日 志 ， 发 现 结果 和 我 们 想 的 完全 不 一 致 ， 正 常情 况 
下 SecondActivity 中 打印 的 sSUserId 的 值 应 该 是 2 才 对 ， 但 是 从 日 志 上 看 
它 竟然 还 是 1， 可 是 我 们 的 确 已 经 在 MainActivity 中 把 sUserId 重 新 赋值 
为 2 了 。 看 到 这 里 ， 大 家 应 该 明 昌 了 这 就 是 多 进程 所 带 来 的 问题 ， 多 进 
程 绝 非 只 是 仅仅 指定 一 个 android:process 属 性 那么 简单 。 


上 述 问 题 出 现 的 原因 是 SecondActivity 运 行 在 一 个 单独 的 进程 中 ， 

我 们 知道 Android 为 每 一 个 应 用 分 配 了 一 个 独立 的 虚拟 机 ， 或 者 说 为 每 
个 进程 都 分 配 一 个 独立 的 虚拟 机 ， 不 同 的 虚拟 机 在 内 存 分 配 上 有 不 同 
的 地 址 空间 ， 这 就 导致 在 不 同 的 虚拟 机 中 访问 同一 个 类 的 对 象 会 产生 
多 份 副本 。 拿 我 们 这 个 例子 来 说 ， 在 进程 com.ryg.chapter 2 和 进程 
com.ryg.chapter_2:remote 中 都 存在 一 个 UserManager 类 ， 并 且 这 两 个 类 
是 互 不 干扰 的 ， 在 一 个 进程 中 修改 sUserId 的 值 只 会 影响 当前 进程 ， 对 
其 他 进程 不 会 造成 任何 有 影响， 这 样 我 们 就 可 以 理解 为 什么 在 
MainActivity 中 修改 了 sUserId 的 值 ， 但 是 在 SecondActivity 中 sUserId 的 
值 却 没有 发 生 改变 这 个 现象 。 


所 有 运行 在 不 同 进程 中 的 四 大 组 件 ， 只 要 它们 之 间 需 要 通过 内 存 
来 共 训 数据 ， 都 会 共 吾 失败 ， 这 也 是 多 进程 所 带 来 的 主要 影响 。 正 和 
情况 下 ， 四 大 组 件 中 间 不 可 能 不 通过 一 些 中 间 层 来 共享 数据 ， 那 么 通 
过 简单 地 指定 进程 名 来 开启 多 进程 都 会 无 法 正确 运行 。 当 然 ， 特 殊 情 
况 下 ， 某 些 组 件 之 间 不 需要 共 至 数据 ， 这 个 时 候 可 以 直接 指定 


android:process 属 性 来 开局 多 进程 ， 但 是 这 种 场景 是 不 常见 的 ， 几 乎 所 
有 情况 都 需要 共享 数据 。 


一 般 来 说 ， 使 用 多 进程 会 造成 如 下 几 方 面 的 问题 : 
(1) 静态 成 员 和 单 例 模式 完全 失效 。 
(2) 线程 同步 机 制 完 全 失效 。 
(3) SharedPreferences 的 可 靠 性 下 降 。 


(4) Application 会 多 次 创建 。 


第 1 个 问题 在 上 面 已 经 进行 了 分 析 。 第 2 个 问题 本 质 上 和 第 一 个 问 
题 是 类 似 的 ， 既 然 都 不 是 一 块 内 存 了 ， 那 么 不 管 是 锁 对 象 还 是 锁 全 局 
类 都 无 法 保证 线程 同步 ， 因 为 不 同 进 程 锁 的 不 是 同一 个 对 象 。 第 3 个 问 
题 是 因为 SharedPreferences 不 文 持 两 个 进程 同时 去 执行 写 操 作 ， 人 否则 会 
导致 一 定 几 率 的 数据 丢失 ， 这 是 因为 SharedPreferences 底 层 是 通过 读 / 
写 XML 文 件 来 实现 的 ， 并 发 写 显 然 是 可 能 出 问题 的 ， 甚 至 并 发 读 / 写 都 
有 可 能 出 问题 。 第 4 个 问题 也 是 显而易见 的 ， 当 一 个 组 件 跑 在 一 个 新 的 
进程 中 的 时 候 ， 由 于 系统 要 在 创建 新 的 进程 同时 分 配 独立 的 虚拟 机 ， 
所 以 这 个 过 程 其实 束 是 局 动 一 个 应 用 的 过 程 。 因 此 ， 相 当 于 系统 又 把 
这 个 应 用 重新 启动 了 一 过 ， 既 然 重 狐 司 动 了 ， 那 么 目 然 会 创建 新 的 
Application。 这 个 问题 其 实 可 以 这 么 理解 ， 运 行 在 同一 个 进程 中 的 组 
件 是 属于 同一 个 虚拟 机 和 同一 个 Application 的 ， 同 理 ， 运 行 在 不 同 进 
程 中 的 组 件 是 属于 两 个 不 同 的 虚拟 机 和 Application 的 。 为 了 更 加 清晰 
地 展示 这 一 点 ， 下 面 我 们 来 做 一 个 测试 ， 首 先 在 Application 的 onCreate 
方法 中 打印 出 当前 进程 的 名 字 ， 然 后 连续 启动 三 个 同一 个 应 用 内 但 属 


于 不 同 进 程 的 Activity， 按 照 期 望 ，Application 的 onCreate 应 该 执行 三 
次 并 打印 出 三 次 进程 名 不 同 的 log， 代 码 如 下 所 示 。 


public class MyApplication extends Application { 
private static final String TAG = "MyApplication"; 
@Override 
public void onCreate() { 
super.onCreate(); 
String processName = 
MyUtils.getProcessName(getApplicationContext(), 
Process.myPid()); 
Log.d(TAG, "application start,process name:" + 
processName); 
} 
J 


运行 后 看 一 下 log， 如 图 2-4 所 示 。 通 过 log 可 以 看 出 ，Application 
执行 了 三 次 onCreate， 并 且 每 次 的 进程 名 称 和 进程 id 都 不 一 样 ， 它 们 的 
进程 名 和 我 们 为 Activity 指 定 的 android:process 属 性 一 致 。 这 也 就 证 实 
了 在 多 进程 模式 中 ， 不 同 进程 的 组 件 的 确 会 拥有 独立 的 虚拟 机 、 
Application 以 及 内 存 空间 ， 这 会 给 实际 的 开发 带 来 很 多 困扰 ， 是 尤其 
需要 注意 的 。 或 者 我 们 也 可 以 这 么 理解 同一 个 应 用 间 的 多 进程 : 它 就 
相当 于 两 个 不 同 的 应 用 采用 了 SharedUID 的 模式 ， 这 样 能 够 更 加 直接 
地 理解 多 进程 模式 的 本 质 。 


Level PID Tag Text 


图 2-4 ”系统 日 志 


本 万 我 们 分 析 了 多 进程 所 读 来 的 问题 ， 但 是 我 们 不 能 因为 多 进程 
有 很 多 问题 就 不 去 正视 它 。 为 了 解决 这 个 问题 ， 系 统 提 供 了 很 多 跨 进 
程 通信 方法 ， 虽 然 说 不 能 直接 地 共享 内 存 ， 但 是 通过 跨 进 程 通 信 我 们 
还 是 可 以 实现 数据 交互 。 实 现 跨 进程 通信 的 方式 很 多 ， 比 如 通过 Intent 
来 传递 数据 ， 共 享 文件 和 SharedPreferences， 基 于 Binder 的 Messenger 和 
AIDL 以 及 Socket 等 ， 但 是 为 了 更 好 地 理解 各 种 IPC 方 式 ， 我 们 需要 移 
熟悉 一 些 基础 概念 ， 比 如 序列 化 相关 的 Serializable 和 Parcelable 接 口 ， 
以 及 Binder 的 概念 ， 熟 悉 完 这 些 基 础 概念 以 后 ， 再 去 理解 各 种 IPC 方 式 
瓯 比较 简单 了 。 


23 IPC 基础 概念 介绍 


本 厄 主 要 介绍 IPC 中 的 一 些 基础 概念 ， 主 要 包含 三 方面 内 容 : 
Serializable 接 口 、Parcelable 接 口 以 及 Binder， 只 有 熟悉 这 三 方面 的 内 
容 后 ， 我 们 才能 更 好 地 理解 跨 进 程 通 信 的 各 种 方式 。Serializable 和 
Parcelable 接 口 可 以 完成 对 象 的 序列 化 过 程 ， 当 我 们 需要 通过 Intent 和 
Binder 传 输 数 据 时 就 需要 使 用 Parcelable 或 者 Serializable。 还 有 的 时 候 
我 们 需要 把 对 象 持久 化 到 存储 设备 上 或 者 通过 网 络 传输 给 其 他 客户 
端 ， 这 个 时 候 也 需要 使 用 Serializable 来 完成 对 象 的 持久 化 ， 下 面 先 介 
绍 如 何 使 用 Serializable 来 完成 对 象 的 序列 化 。 


2.3.1 Serializable#2O 


Serializable 是 Java 所 提供 的 一 个 序列 化 接口 ， 它 是 一 个 空 接 口 ， 为 
对 象 提供 标准 的 序列 化 和 反 序 列 化 操作 。 使 用 Serializable 来 实现 序列 
化 相当 人 简单， 只 需要 在 类 的 声明 中 指定 一 个 类 似 下 面 的 标识 即 可 目 动 
实现 默认 的 序列 化 过 程 。 


private static final long serialVersionUID = 


8711368828010083044L 


在 Android 中 也 提供 了 新 的 序列 化 方式 ， 那 瓯 是 Parcelable 接 口 ， 使 
用 Parcelable 来 实现 对 象 的 序列 号 ， 其 过 程 要 稍微 复杂 一 些 ， 本 世人 先 介 
绍 Serializable 接 口 。 上 面 提 到 ， 想 让 一 个 对 象 实现 序列 化 ， 只 需要 这 
个 类 实现 Serializable 接 口 并 声明 一 个 serialVersionUID 即 可 ， 实 际 上 ， 
甚至 这 个 serialVersionUID 也 不 是 必需 的 ， 我 们 不 声明 这 个 
serialVersionUID 同 样 也 可 以 实现 序列 化 ， 但 是 这 将 会 对 反 序 列 化 过 程 
产生 影响 ， 具 体 什 么 影响 后 面 再 介绍 。User 类 就 是 一 个 实现 了 
Serializable 接 口 的 类 ， 它 是 可 以 被 序列 化 和 反 序 列 化 的 ， 如 下 所 示 。 


public class User implements Serializable { 
private static final long serialVersionUID = 
519067123721295773L; 
public int userId; 
public String userName; 


public boolean isMale; 


} 
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几乎 所 有 工作 都 被 系统 目 动 完 成 了 。 如 何 进 行 对 象 的 序列 化 和 反 序 列 


化 也 非常 徐 单 ， 只 需要 采用 ObjectOutputStream 和 ObjectInputStream 即 
可 轻松 实现 。 下 面 举 个 简单 的 例子 。 


// 序 列 化 过 程 

User user = new User(0, "jake", true); 

ObjectOutputStream out = new ObjectOutputStream( 
new FileOutputStream("cache.txt")); 

out.writeObject(user); 

out.close(); 

// 反 序列 化 过 程 

ObjectInputStream in = new ObjectInputStream( 
new FileInputStream("cache.txt")); 

User newUser = (User) in.readObject(); 


in.close(); 


上 述 代 码 演示 了 采用 Serializable 方 式 序列 化 对 象 的 典型 过 程 ， 很 
人 简单， 只 需要 把 实现 了 Serializable 接 口 的 User 对 象 写 到 文件 中 区 可 以 
快速 恢复 了 ， 人 恢复 后 的 对 象 newUser 和 user 的 内 容 完全 一 样 ， 但 是 两 者 
并 不 是 同一 个 对 象 。 


刚 开 始 提 到 ， 即 使 不 指定 serialVersionUID 也 可 以 实现 序列 化 ， 那 
到 底 要 不 要 指定 呢 ? 如果 指定 的 话 ，serialVersionUID 后 面 那 一 长 串 数 
字 又 是 什么 含义 呢 ? 我 们 要 明白 ， 系统 既然 提供 了 这 个 
serialVersionUID， 那 么 它 必须 是 有 用 的 。 这 个 serialVersionUID 是 用 来 
辅助 序列 化 和 反 序 列 化 过 程 的 ， 原 则 上 序列 化 后 的 数据 中 的 
serialVersionUID 只 有 和 当前 类 的 serialVersionUID 相 同 才 能 够 正常 地 被 
反 序 列 化 。serialVersionUID 的 详细 工作 机 制 是 这 样 的 : 序列 化 的 时 候 
系统 会 把 当前 类 的 serialVersionUID 写 入 序列 化 的 文件 中 〈 也 可 能 是 其 


他 中 介 ) ， 当 反 序 列 化 的 时 候 系 统 会 去 检测 文件 中 的 
serialVersionUID ， 看 它 是 否 和 当前 类 的 serialVersionUID 一 致 ， 如 果 一 


致 束 说 明 序 列 化 的 类 的 版 本 和 当前 类 的 版 本 古 相 同 的 ， 这 个 时 候 可 以 
成 功 反 序列 化 ， 否 则 避 ® 说 明 当 前 类 和 序列 化 的 类 相 比 发 生 了 某 些 变 


换 ， 比 如 成 员 变 量 的 数量 、 类 型 可 能 发 生 了 改变 ， 这 个 时 候 是 无 法 正 
常 反 序列 化 的 ， 因 此 会 报 如 下 错误 : 


java.io.InvalidClassException: Main; local class 
incompatible: stream 
classdesc serialVersionUID = 8711368828010083044, local 
class serial- 


VersionUID = 8711368828010083043 ° 


一 般 来 说 ， 我 们 应 该 手动 指定 serialVersionUID 的 值 ， 比 如 1L， 人 也 
可 以 让 Eclipse 根据 当前 类 的 结构 目 动 去 生成 它 的 hash 值 ， 这 样 序列 化 
和 有 反 序 列 化 时 两 者 的 serialVersionUID 是 相同 的 ， 因 此 可 以 正常 进行 反 
序列 化 。 如 果 不 手 动 指定 serialVersionUID 的 值 ， 反 序列 化 时 当前 类 有 
所 改变 ， 比 如 增加 或 者 删除 了 某 些 成 员 变 量 ， 那 么 系统 就 会 重新 计算 
当前 类 的 hash 值 并 把 它 赋值 给 serialVersionUID， 这 个 时 候 当 前 类 的 
serialVersionUID 残 和 序列 化 的 数据 中 的 serialVersionUID 不 一 致 ， 于 是 
反 序 列 化 失败 ， 程 序 束 会 出 现 crash。 所 以 ,我 们 可 以 明显 感觉 到 
serialVersionUID 的 作用 ， 当 我 们 手动 指定 了 它 以 后 ， 就 可 以 在 很 大 程 
度 上 避免 反 序 列 化 过 程 的 失败 。 比 如 当 版 本 升级 后 ， 我 们 可 能 删除 了 
某 个 成 员 变 量 也 可 能 增加 了 一 些 新 的 成 员 变 量 ， 这 个 时 候 我 们 的 反问 
序列 化 过 程 仍然 能 够 成 功 ， 程 序 仍然 能 够 最 大 限度 地 恢复 数据 ， 相 
反 ， 如 果 不 指 定 serialVersionUID 的 话 ， 程 序 则 会 挂 掉 。 当 然 我 们 还 要 
考虑 另外 一 种 情况 ， 如 采 类 结构 发 生 了 非常 规 性 改变 ， 比 如 修改 了 类 


名 ， 修 改 了 成 员 变 量 的 类 型 ， 这 个 时 候 尽 管 serialVersionUID 难 证 通过 
了 ,但 是 反 序列 化 过 程 还 是 会 失败 ， 因 为 类 结构 有 了 毁灭 性 的 改变 ， 
根本 无 法 从 老 版 本 的 数据 中 还 原 出 一 个 新 的 类 结构 的 对 象 。 


根据 上 面 的 分 析 ， 我 们 可 以 知道 ， 给 serialVersionUID 指 定 为 二 或 
者 采用 Eclipse 根据 当前 类 结构 去 生成 的 hash 值 ， 这 两 者 并 没有 本 质 区 
别 ， 效 果 完 全 一 样 。 以 下 两 点 需要 特别 提 一 下 ， 首 先 静 态 成 员 变 量 属 
于 类 不 属于 对 象 ， 所 以 不 会 参与 序列 化 过 程 ， 其 次 用 transient 关 键 字 标 
记 的 成 员 变 量 不 参与 序列 化 过 程 。 


男 外 ， 系 统 的 默认 序列 化 过 程 也 是 可 以 改变 的 ， 通 过 实现 如 下 两 
个 方法 即 可 重 写 系统 默认 的 序列 化 和 反 序 列 化 过 程 ， 有 具体 怎么 去 重 写 
这 两 个 方法 束 古 很 简单 的 事 了 ， 这 里 就 不 再 详细 介绍 了 ， 毕 竞 这 不 是 
本 章 的 重点 ， 而 且 大 部 分 情况 下 我 们 不 需要 重 写 这 两 个 方法 。 


private void writeObject(java.io.ObjectOutputStream out) 
throws IOException { 
MU WPIC (ons CO SOUE" ani 
} 
private void readObject(java.io.ObjectInputStream in) 
throws IOException,ClassNotFoundException { 
// populate the fields of 'this' from the data in 'in'... 
} 


2.3.2 Parcelable& O 


上 一 节 我 们 介绍 了 通过 Serializable 方 式 来 实现 序列 化 的 方法 ， 本 
节 接 着 介绍 另 一 种 序列 化 方式 : Parcelable。Parcelable 也 是 一 个 接口 ， 
只 要 实现 这 个 接口 ， 一 个 类 的 对 象 就 可 以 实现 序列 化 并 可 以 通过 Intent 
和 Binder 传 递 。 下 面 的 示例 是 一 个 典型 的 用 法 。 


Creator<User>() { 
public User createFromParcel(Parcel in) { 
return new User(in); 
} 
public User[] newArray(int size) { 


return new User[size]; 


}; 
private User(Parcel in) { 
userId = in.readInt(); 
userName = in.readString(); 
isMale = in.readInt() == 1; 
book = 
in.readParcelable(Thread.currentThread().getContextClass- 


Loader()); 


} 


这 里 先 说 一 下 Parcel，Parcel 内 部 包装 了 可 序列 化 的 数据 ， 可 以 在 
Binder 中 自由 传输 。 从 上 述 代 码 中 可 以 看 出 ， 在 序列 化 过 程 中 需要 实 
现 的 功能 有 序列 化 、 反 序列 化 和 内 容 措 述 。 序 列 化 功能 
writeToParcel 方 法 来 完成 ， 最 终 是 通过 Parcel 中 的 一 系列 write 方法 来 完 
成 的 ， 反 序列 化 功能 由 CREATOR 来 完成 ， 其 内 部 标明 了 如 何 创建 序 
列 化 对 象 和 数组 ， 并 通过 Parcel 的 一 系列 read 方 法 来 完成 反 序 列 化 过 
E; 内 容 描述 功能 由 describeContents 方 法 来 完成 ， 儿 乎 在 所 有 情况 下 
这 个 方法 都 应 该 返回 0， 仅 当当 前 对 象 中 存在 文件 描述 符 时 ， 此 方法 返 
回 1。 需 要 注意 的 是 ， 在 User(Parcel in) 方 法 中 ， 由 于 book 是 男 一 个 可 


序列 化 对 象 ， 所 以 它 的 反 序列 化 过 程 需要 传递 当前 线程 的 上 下 文 类 加 
载 右 ， 人 否则 会 报 无 法 找到 类 的 错误 。 详 细 的 方法 说 明 请 参看 表 2-1。 


表 2-1 Parcelable 的 方法 说 明 


从 序列 化 后 的 对 象 中 创建 原始 对 象 
创建 指定 长 度 的 原始 对 象 数 组 
从 序列 化 后 的 对 象 中 创建 原始 对 象 

将 当前 对 象 写 入 序列 化 结构 中 ， 其 中 flags 


标识 有 两 种 值 : 0 或 者 1 (参见 右 侧 标记 位 )。 
为 1 时 标识 当前 对 象 需要 作为 返回 值 返回 ， 不 
能 立即 释放 资源 ， 几 乎 所 有 情况 都 为 0 

返回 当前 对 象 的 内 容 描述 。 如 果 含有 文件 描 
述 符 ， 返 回 1 (参见 右 侧 标记 位 )， 否则 返回 0，| CONTENTS_FILE_DESCRIPTOR 
几乎 所 有 情况 都 返回 0 


PARCELABLE_WRITE_RETURN_VALUE 


系统 已 经 为 我 们 提供 了 许多 实现 了 Parcelable 接 口 的 类 ， 它 们 都 是 
可 以 直接 序列 化 的 ， 比 如 Intent、Bundle、Bitmap 等 ， 同 时 List 和 Map 
也 可 以 序列 化 ， 前 提 是 它们 里 面 的 每 个 元 素 都 是 可 序列 化 的 。 


既然 Parcelable 和 Serializable 都 能 实现 序列 化 并 且 都 可 用 于 Intent 间 
的 数据 传递 ， 那 么 二 者 该 如 何 选取 呢 ? Serializable 是 Java 中 的 序列 化 接 
口 ， 其 使 用 起 来 简单 但 是 开销 很 大 ， 序 列 化 和 反 序 列 化 过 程 需要 大 量 
IO 探 作 。 而 Parcelable 是 Android 中 的 序列 化 方式 ， 因 此 更 适合 用 在 
Android 平 台 上 ， 龙 的 缺点 束 是 使 用 起 来 稍微 麻烦 点 ， 但 是 它 的 效率 很 
高 ， 这 是 Android 推 荐 的 序列 化 方式 ， 此 我 们 要 首选 Parcelable 。 
Parcelable 主 要 用 在 内 存 序列 化 上 ， 通 过 Parcelable 将 对 象 序列 化 到 存储 
设备 中 或 者 将 对 象 序列 化 后 通过 网 络 传输 也 都 是 可 以 的 ， 但 是 这 个 过 
程 会 稍 显 复杂 ， 因 此 在 这 两 种 情况 下 建议 大 家 使 用 Serializable。 以 上 
WL Parcelable#ll Serializable #ll X. ° 


2.3.3 Binder 


Binder 是 一 个 很 深入 的 话题 ， 笔 者 也 看 过 一 些 别人 写 的 Binder 相 关 
的 文章 ， 发 现 很 少 有 人 能 把 它 介 绍 清楚 ， 不 是 深入 代码 细 廊 不 能 目 
KM, DERHATTATZ, AER ER ° ATL, ATE 
者 不 打算 深入 探讨 Binder 的 底层 细节 ， 因 为 Binder 太 复杂 了 。 本 市 的 侧 
重点 是 介绍 Binder 的 使 用 以 及 上 层 原理 ， 为 接 下 来 的 几 节 内 容 做 铺 


Ho 


直观 来 说 ，Binder 是 Android 中 的 一 个 类 ， 它 继承 了 IBinder 接 口 。 
从 IPC 角 上 度 来 说 ，Binder 是 Android 中 的 一 种 路 进程 通信 方式 ，Binderj 不 
可 以 理解 为 一 种 虚拟 的 物理 设备 ， 它 的 设备 张 动 是 /dewbinder， 该 通 
信 方 式 在 Linux 中 没有 ; M Android Framework A E Æw, Binder 
ServiceManager JE 接 各 种 Manager ( ActivityManager 
WindowManager ， 等 等 ) 和 相应 ManagerService 的 桥梁 ;从 Android 应 
用 层 来 说 ，Binder 是 客户 端 和 服务 端 进行 通信 的 媒介 ， 当 bindService 的 
时 候 ， 服 务 端 会 返回 一 个 包含 了 服务 端 业 务 调用 的 Binder 对 象 ， 通 过 
这 个 Binder 对 象 ， 客 户 问 就 可 以 获取 服务 端 提 供 的 服务 或 者 数据 ， 这 
里 的 服务 包括 普通 服务 和 基于 AIDL 的 服务 。 


Android 开 发 中 ，Binder 主 要 用 在 Service 中 ， 包 括 AIDL 和 
Messenger， 其 中 普通 Service 中 的 Binder 不 涉及 进程 间 通 信 ， 所 以 较为 
人 简单， 无 法 触及 Binder 的 核心 ， 而 Messenger 的 故 层 其 实 是 AIDL， 所 以 
这 里 选择 用 AIDL 来 分 析 Binder 的 工作 机 制 。 为 了 分 析 Binder 的 工作 机 
制 ， 我 们 需要 新 建 一 个 AIDL 示 例 ，SDK 会 自动 为 我 们 生产 AIDL 所 对 
应 的 Binder 类 ， 然 后 我 们 就 可 以 分 析 Binder 的 工作 过 程 。 还 是 采用 本 章 
开始 时 用 的 例子 ， 新 建 Java 包 com.ryg.chapter_2.aidl|， 然 后 新 建 三 个 文 
件 Book.java、Book.aidl 和 IBookManageraidl， 代 人 码 如 下 所 示 。 


ti 
private Book(Parcel in) { 
bookId = in.readInt(); 


bookName = in.readString(); 


} 
//Book.aidl 


package com.ryg.chapter_2.aidl; 
parcelable Book; 
// IBookManager .aidl 
package com.ryg.chapter_2.aidl; 
import com.ryg.chapter_2.aidl.Book; 
interface IBookManager { 

List<Book> getBookList(); 
void addBook(in Book book); 
} 


上 面 三 个 文件 中 ，Book.java 是 一 个 表示 图 书信 息 的 类 ， 它 实现 了 
Parcelable 接 @ ° Book.aidl 是 Book 类 在 AIDL 中 的 声明 。 
IBookManager.aidl 是 我 们 定义 的 一 个 接口 ， 里 面 有 两 个 方法 : 
getBookList 和 addBook， 其 中 getBookList 用 于 从 远程 服务 端 获 取 图 书 列 
表 ， 而 addBook 用 于 往 图 书 列表 中 添加 一 本 书 ， 当 然 这 两 个 方法 主要 
是 示例 用 ， 不 一 定 要 有 实际 意义 。 我 们 可 以 看 到 ， 尽 管 Book 类 已 经 和 
IBookManager 位 于 相同 的 包 中 ， 但 是 在 IBookManager 中 仍然 要 导入 
Book 类 ， 这 束 是 AIDL 的 特殊 之 处 。 下 面 我 们 先 看 一 下 系统 关 
IBookManager.aidl Æ 产 HY Binder 类 , 7E gen 目录 和 下 的 
com.ryg.chapter_2.aidl] 包 中 有 一 个 IBookManager.java 的 类 ， 这 束 是 我 们 


要 找 的 类 。 接 下 来 我 们 需要 根据 这 个 系统 生成 的 Binder 类 来 分 析 Binder 
的 工作 原理 ， 代 码 如 下 : 


public java.util.List<com.ryg.chapter_2.aidl.Book> 
getBookList() 
throws android.os.RemoteException; 
public void addBook(com.ryg.chapter_2.aidl.Book book) 


throws android.os.RemoteException; 


} 


上 述 代 码 是 系统 生成 的 ， 为 了 方便 查看 笔者 稍微 做 了 一 下 格式 上 
的 调整 。 在 gen 目 录 下 ， 可 以 看 到 根据 IBookManager.aidl 系 统 为 我 们 生 
成 了 IBookManager.java 这 个 类 ， 它 继承 了 IInterface 这 个 接口 ， 同 时 它 
目 己 也 还 是 个 接口 ， 所 有 可 以 在 Binder 中 传输 的 接口 都 需要 继承 
IInterface 接 口 。 这 个 类 刚 开 始 看 起 来 逻辑 混乱 ， 但 是 实际 上 还 是 很 清 
蜥 的， 通过 它 我 们 可 以 清楚 地 了 解 到 Binder 的 工作 机 制 。 这 个 类 的 结 
构 其 实 很 简单 ， 首 移 ， 它 声明 了 两 个 方法 getBookList 和 addBook， 显 
然 这 就 是 我 们 在 IBookManager.aidl 中 所 声明 的 方法 ， 同 时 它 还 声明 了 
两 个 整 型 的 id 分 别 用 于 标识 这 两 个 方法 ， 这 两 个 id 用 于 标识 在 transact 
过 程 中 客户 端 所 请 求 的 到 展 是 哪个 方法 。 接 着 ， 它 声明 了 一 个 内 部 类 
Stub， 这 个 Stub 束 是 一 个 Binder 类 ， 当 客户 端 和 服务 端 都 位 于 同一 个 进 
程 时 ， 方 法 调用 不 会 走 跨 进 Sa 而 当 两 者 位 于 不 同 进 程 
上 时， 方法 调用 需要 走 transact 过 程 ， 这 个 逻辑 由 Stub 的 内 部 代理 类 Proxy 
来 完成 。 这 人 么 来 看 ，IBookManager 这 个 接口 的 确 很 简单 ， 但 是 我 们 也 
应 该 认识 到 ， 这 个 接口 的 核心 实现 就 是 它 的 内 部 类 Stub 和 Stub 的 内 部 
代理 类 Proxy， 下 面 详细 介绍 针对 这 两 个 类 的 每 个 方法 的 舍 义 。 


DESCRIPTOR 


Binder 的 唯一 标识 ， 一 般 用 当前 Binder 的 类 名 表示 ， 比 如 本 例 中 
的 “com.ryg.chapter_2.aidl.IBookManager”。 


asInterface(android.os.IBinder obj) 


用 于 将 服务 端的 Binder 对 象 转换 成 客户 端 所 需 的 AIDL 接 口 类 型 的 
对 象 ， 这 种 转换 过 程 是 区 分 进程 的 ， 如 果 客 户 端 和 服务 端 位 于 同一 进 
程 ， 那 么 此 方法 返回 的 就 是 服务 端的 Stub 对 象 本 身 ， 和 否则 返回 的 是 系 
统 封 装 后 的 Stub.proxy 对 象 。 


asBinder 
此 方法 用 于 返回 当前 Binder 对 象 。 
onTransact 


这 个 方法 运行 在 服务 端 中 的 Binder 线 程 池 中 ， 当 客户 端 发 起 跨 进 
程 请 求 时 ， 远 程 请 求 会 通过 系统 底层 封闭 后 区 由 此 方法 来 处 理 。 该 方 
法 的 原型 为 public Boolean onTransact(int code,android.os.Parcel 
data,android.os.Parcel reply,int flags) ° 服务 端 通 过 code 可 以 确定 客户 端 
所 请 求 的 目标 方法 是 什么 ， 搂 着 从 data 中 取出 目标 方法 所 需 的 参数 
(如 果 目 标 方法 有 参数 的 话 ) ， 然 后 执行 目标 方法 。 当 目标 方法 执行 
完毕 后 ， 就 同 reply 中 写 入 返回 值 (如 果 目 标 方法 有 返回 值 的 话 ) ， 
onTransact 方 法 的 执行 过 程 就 是 这 样 的 。 需 要 注意 的 是 ， 如 果 此 方法 返 
回 false， 那 么 客户 端的 请 求 会 失败 ， 因 此 我 们 可 以 利用 这 个 特性 来 做 
权限 验证 ， 上 毕竟 我们 也 不 希望 随便 一 个 进程 都 能 远程 调用 我 们 的 服 
务 。 


Proxy#getBookList 


这 个 方法 运行 在 客户 端 ， 当 客户 端 远程 调用 此 方法 时 ， 它 的 内 部 
实现 是 这 样 的 : 首先 创建 该 方法 所 需要 的 输入 型 Parcel 对 象 _data、 输 


出 型 Parcel 对 象 reply 和 返回 值 对 象 List;， 然后 把 该 方法 的 参数 信息 写 
入 _data 中 (如 果 有 参数 的 话 ) ; 接着 调用 transact 方 法 来 发 起 RPC ( 远 
程 过 程 调用 ) 请 求 ， 同 时 当前 线程 挂 起 ， 人 然后 服务 端的 onTransact 方 法 
会 被 调用 ， 直 到 RPC 过 程 返回 后 ， 当 前 线程 继续 执行 ， 并 从 _reply 中 取 
出 RPC 过 程 的 返回 结果 ; 最 后 返回 _reply 中 的 数据 。 


Proxy#addBook 


这 个 方法 运行 在 客户 端 ， 它 的 执行 过 程 和 getBookList 是 一 样 的 ， 
addBook 没 有 返回 值 ， 所 以 它 不 需要 从 _reply 中 取出 返回 值 。 


通过 上 面 的 分 析 ， 读 者 应 该 已 经 了 解 了 Binder 的 工作 机 制 ， 但 是 
有 两 点 还 是 需要 额外 说 明 一 下 首先 ， 当 客户 端 发 起 远程 请 求 时 ， 由 
于 当前 线程 会 被 挂 起 直至 服务 端 进程 返回 数据 ， 所 以 如 果 一 个 远程 方 
法 是 很 耗 时 的 ， 那 么 不 能 在 UI 线 程 中 发 起 此 远程 请 求 ; 其 次 ， 由 于 服 
务 端的 Binder 方 法 运行 在 Binder 的 线程 池 中 ， 所 以 Binder 方 法 不 管 是 否 
耗 时 都 应 该 采用 同步 的 方式 去 实现 ， 因 为 它 已 经 运行 在 一 个 线程 中 
了 。 为 了 更 好 地 说 明 Binder， 下 面 给 出 一 个 Binder 的 工作 机 制图 ， 如 图 
2-5 所 示 。 


返回 数据 SS, data Transact 
唤醒 Client 写 入 参数 —_ | 
Client ix Ri Binder | | een 
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&]2-5 “Binder 的 工作 机 制 


从 上 述 分 析 过 程 来 看 ， 我 们 完全 可 以 不 提供 AIDL 文 件 即 可 实现 
Binder， 之 所 以 提供 AIDL 文 件 ， 是 为 了 方便 系统 为 我 们 生成 代码 。 系 
统 根据 AIDL 文 件 生成 Java 文 件 的 格式 是 固定 的 ， 我 们 可 以 执 开 AIDL 
文件 直接 写 一 个 Binder 出 来 ， 接 下 来 我 们 就 介绍 如 何 手 动 写 一 个 
Binder。 还 是 上 面 的 例子 ， 但 是 这 次 我 们 不 提供 AIDL 文 件 。 参 考 上 面 
系统 目 动 生 成 的 IBookManagerjava 这 个 类 的 代码 ， 可 以 发 现 这 个 类 是 
相当 有 规律 的 ， 根 据 它 的 特点 ， 我 们 完全 可 以 目 己 写 一 个 和 它 一 模 一 
样 的 类 出 来 ， 然 后 这 个 不 借助 AIDL 文 件 的 Binder 就 完成 了 。 但 是 我 们 
发 现 系统 生成 的 类 看 起 来 结构 不 清晰 ， 我 们 想 试 着 对 它 进 行 结构 上 的 
调整 ， 可 以 发 现 这 个 类 主要 由 两 部 分 组 成 ， 首 移 它 本 号 是 一 个 Binder 
的 接口 (继承 了 IInterface) ， 其 次 它 的 内 部 由 个 Stub 类 ， 这 个 类 就 是 
个 Binder。 还 记得 我 们 怎么 写 一 个 Binder 的 服务 端 吗 ? 代码 如 下 所 示 。 


private final IBookManager.Stub mBinder = new 
IBookManager.Stub() { 
@Override 


public List<Book> getBookList() throws RemoteException 


synchronized (mBookList) { 


return mBookList; 


t 
@Override 
public void addBook(Book book) throws RemoteException { 
synchronized (mBookList) { 
if (!mBookList.contains(book)) { 


mBookList .add( book); 


自 先 我 们 会 实现 一 个 创建 了 一 个 Stub 对 象 并 在 内 部 实现 
IBookManager 的 接口 方法 ， 然 后 在 Service 的 onBind 中 返回 这 个 Stub 对 
象 。 因此 ， 从 这 一 点 来 看 ， 我 们 完全 可 以 把 Stub 类 提取 出 来 直接 作为 
一 个 独立 的 Binder 类 来 实现 ， 这 样 IBookManager 中 就 只 剩 接口 本 续 
了 ， 通 过 这 种 分 离 的 方式 可 以 让 它 的 结构 变 得 清晰 点 。 


根据 上 面 的 思想 ， 手 动 实现 一 个 Binder 可 以 通过 如 下 步骤 来 完 
成 : 


(1) 声明 一 个 AIDL 性 质 的 接口 ， 只 需要 继承 IImnterface 接 口 即 
可 ，IInterface 接 口中 只 有 一 个 asBinder 方 法 。 这 个 接口 的 实现 如 下 : 


public interface IBookManager extends IInterface { 
static final String DESCRIPTOR = 
"com.ryg.chapter_2.manualbinder. 
IBookManager"; 
static final int TRANSACTION _getBookList = 
IBinder. FIRST_CALL_TRANSA- 
CTION + O; 
static final int TRANSACTION_addBook = 
IBinder .FIRST_CALL_TRANSACTION 
ape de 


public List<Book> getBookList() throws 


RemoteException; 
public void addBook(Book book) throws RemoteException; 


} 


可 以 看 到 ， 在 接口 中 声明 了 一 个 Binder 朱 述 符 和 另外 两 个 id， 这 两 
个 id 分 别 表示 的 是 getBookList 和 addBook 方 法 ， 这 上段 代码 原本 也 是 系统 
生成 的 ， 我 们 仿照 系统 生成 的 规则 去 手动 书写 这 部 分 代码 。 如 采 我 们 
有 三 个 方法 ， 应 该 怎么 做 呢 ? 很 显然 ， 我们 要 再 声明 一 个 id， 然 后 按 
照 固 定 模式 声明 这 个 新 方法 即 可 ， 这 个 比较 好 理解 ， 不 再 多 说 。 


(2) 实现 Stub 类 和 Stub 类 中 的 Proxy 代 理 类 ， 这 上段 代码 我 们 可 以 
ACS, 但 是 写 出 来 后 会 发 现 和 系统 自动 生成 的 代码 是 一 样 的， 因此 
这 个 Stub 类 我 们 只 需要 参考 系统 生成 的 代码 即 可 ， 只 是 结构 上 需要 做 
一 下 调整 ， 调 整 后 的 代码 如 下 所 示 。 


public class BookManagerImpl extends Binder implements 
IBookManager { 
/** Construct the stub at attach it to the interface. 
27 
public BookManagerImpl() { 
this.attachInterface(this, DESCRIPTOR); 


JE 
* Cast an IBinder object into an IBookManager 
interface, generating a 
proxy 
* if needed. 


we 


data.recycle(); 


} 


通过 将 上 述 代 码 和 系统 生成 的 代码 对 比 ， 可 以 发 现 人 简直 是 一 模 一 
样 的 。 也 许 有 人 会 问 : 既然 和 系统 生成 的 一 模 一 样 ， 那 我 们 为 什么 要 
手动 去 写 呢 ?我们 在 实际 开发 中 完全 可 以 通过 AIDL 文 件 让 系统 去 目 动 
生成 ， 手 动 去 写 的 意义 在 于 可 以 让 我 们 更 加 理解 Binder 的 工作 原理 ， 
同时 也 提供 了 一 种 不 通过 AIDL 文 件 来 实现 Binder 的 新 方式 。 也 就 是 
说 ，AIDL 文 件 并 不 是 实现 Binder 的 必需 品 。 如 果 是 我 们 手写 的 
Binder， 那 么 在 服务 端 只 需要 创建 一 个 BookManagerImpl 的 对 象 并 在 
Service 的 onBind 方 法 中 返回 即 可 。 最 后 ， 是 否 手动 实现 Binder 没 有 本 
质 区 别 ， 二 者 的 工作 原理 完全 一 样 ，AIDL 文 件 的 本 质 是 系统 为 我 们 提 
供 了 一 种 快速 实现 Binder 的 工具 ， 仅 此 而 已 。 


接 下 来 ， 我 们 介绍 Binder 的 两 个 很 重要 的 方法 linkIoDeath 和 
unlinkToDeath。 我 们 知道 ，Binder 运 行 在 服务 端 进 程 ， 如 果 服 务 端 进 
程 由 于 某 种 原因 异 弟 终止， 这 个 时 候 我 们 到 服务 端的 Binder 连 接 断 裂 

( 称 之 为 Binder 死 亡 ) ， 会 导致 我 们 的 远程 调用 失败 。 更 为 关键 的 
是 ， 如 果 我 们 不 知道 Binder 连 接 已 经 断裂 ， 那 么 客户 端的 功能 束 会 受 
到 影响 。 为 了 解决 这 个 问题 ，Binder 中 提供 了 两 个 配对 的 方法 
linkToDeath 和 unlinkToDeath ， 通 过 linkToDeath 我 们 可 以 给 Binder 设 置 
一 个 死亡 代理 ， 当 Binder 死 亡 时 ， 我 们 就 会 收 到 通知 ， 这 个 时 候 我 们 
束 可 以 重新 发 起 连接 请 求 从 而 恢复 连接 。 那 么 到 的 如 何 给 Binder 设 置 
死亡 代理 呢 ? 也 很 简单 。 


首先 ， 声 明 一 个 DeathRecipient 对 象 。DeathRecipient 是 一 个 接口 ， 
其 内 部 只 有 一 个 方法 binderDied， 我 们 需要 实现 这 个 方法 ， 当 Binder 死 
亡 的 时 候 ， 系 统 束 会 回调 binderDied 方 法 ， 然 后 我 们 就 可 以 移出 之 前 绑 
定 的 binder 代 理 并 重 狐 绑 定 远程 服务 : 


private IBinder.DeathRecipient mDeathRecipient = new 
IBinder.Death- 
Recipient() { 
@Override 
public void binderDied() { 
if (mBookManager == null) 


return; 


mBookManager .asBinder ().unlinkToDeath(mDeathRecipient, 0); 
mBookManager = null; 


// TODO: 这 里 重新 绑 定 远程 Service 


y; 
其 次 ， 在 客户 端 绑 定 远程 服务 成 功 后 ， 给 binder 设 置 死 亡 代 理 : 


mService = IMessageBoxManager.Stub.asInterface(binder); 


binder.linkToDeath(mDeathRecipient,0); 


其 中 linkToDeath 的 第 二 个 参数 是 个 标记 位 ， 我 们 直接 设 为 0 即 可 。 

经 过 上 面 两 个 步骤 ， 残 双 a 当 Binder 死 亡 

的 时 候 我 们 束 可 以 收 到 通知 了 。 另 外 ， 通 过 Binder 的 方法 isBinderAlive 
也 可 以 判断 Binder 是 否 死 亡 。 


到 这 里 ，IPC 的 基础 知识 就 介绍 完毕 了 ， 下 面 开始 进入 正题 ， 直 
面 形形色色 的 进程 间 通 信 方 式 。 


2.4 Android 中 的 IPC 方 式 


在 上 下 中 ， 我 们 介绍 了 IPC 的 几 个 基础 知识 : 序列 化 和 Binder， 本 
忆 开 始 详细 分 析 各 种 器 进程 通信 方式 。 有 具体 方式 有 很 多 ， 比 如 可 以 通 
过 在 Intent 中 附加 extras 来 传递 信息 ， 或 者 通过 共享 文件 的 方式 来 共享 
数据 ， 还 可 以 采用 Binder 方 式 来 器 进 程 通 信 ， 另 外 ，ContentProvider 天 
生 束 是 支持 跨 进 程 访 问 的 ， 因 此 我 们 也 可 以 采用 它 来 进行 IPC。 此 
外 ， 通 过 网 络 通信 也 是 可 以 实现 数据 传递 的 ， 所 以 Socket 也 可 以 实现 
IPC。 上 述 所 说 的 各 种 方法 都 能 实现 IPC， 它 们 在 使 用 方法 和 侧重 点 上 
都 有 很 大 的 区 别 ， 下 面 会 一 一 进行 展开 。 


2.4.1 使 用 Bundle 


我 们 知道 ， 四 大 组 件 中 的 三 大 组 件 (Activity ` Service ` 
Receiver) 都 是 支持 在 Intent 中 传递 Bundle 数 据 的 ， 由 于 Bundle 实 现 了 
Parcelable 接 口 ， 所 以 它 可 以 方便 地 在 不 同 的 进程 间 传 输 。 基 于 这 一 
点 ， 当 我 们 在 一 个 进程 中 启动 了 男 一 个 进程 的 Activity、Service 和 
Receiver， 我 们 就 可 以 在 Bundle 中 附加 我 们 需要 传输 给 远程 进程 的 信息 
并 通过 Intent 发 送出 去 。 当 然 ， 我 们 传输 的 数据 必须 能 够 被 序列 化 ， 比 
如 基本 类 型 、 实 现 了 Parcellable 接 口 的 对 象 、 实 现 了 Serializable 接 口 的 
对 象 以 及 一 些 Android 文 持 的 特殊 对 象 ， 具 体内 容 可 以 看 Bundle 这 个 
类 ， 就 可 以 看 到 所 有 它 支 持 的 类 型 。Bundle 不 支持 的 类 型 我 们 无 法 通 


VTA OE, AARE, MARS Y REM 
最 简单 的 进程 间 通 信 方 式 ， 


除了 直接 传递 数据 这 种 典型 的 使 用 场景 ， 它 还 有 一 种 特殊 的 使 用 
场景 。 比 如 A 进程 正在 进行 一 个 计算 ， HA ERABE 
个 组 件 并 把 计算 结果 传递 给 B 进 程 ， 可 是 遗憾 的 是 这 个 计算 结果 不 文 
持 放 入 Bundle 中 ， 因 此 无 法 通过 Intent 来 传输 ， 这 个 时 候 如 果 我 们 用 其 
他 IPC 方 式 就 会 略 显 复杂 。 可 以 考虑 如 下 方式 : 我 们 通过 Intent 局 动 进 
程 B 的 一 个 Service 组 件 (比如 IntentService) ， 让 Service 在 后 台 进 行 计 
第， 计算 完毕 后 再 启动 B 进 程 中 真正 要 启动 的 目标 组 件 ， 由 于 Service 
也 运行 在 B 进 程 中 ， 所 以 目标 组 件 惑 可 以 直接 获取 计算 结 采 ， 这 样 一 
来 就 轻松 解决 了 路 进程 的 问题 。 这 种 方式 的 核心 思想 在 于 将 原本 需要 
在 A 进程 的 计算 任务 转移 到 B 进 程 的 后 人 台 Service 中 去 执行 ， 这 样 就 成 功 
地 避免 了 进程 间 通 信 问 题 ， 而 且 只 用 了 很 小 的 代价 。 


2.4.2 ”使 用 文件 共享 


共享 文件 也 是 一 种 不 错 的 进程 间 通 信 方 式 ， 两 个 进程 通过 读 / 写 同 
一 个 文件 来 交换 数据 ， 比 如 A 进 程 把 数据 写 入 文件 ，B 进 程 通过 读 取 这 
个 文件 来 获取 数据 。 我 们 知道 ， 在 Windows 上 ， 一 个 文件 如 果 被 加 了 
排斥 锁 将 会 导致 其 他 线程 无 法 对 其 进行 访问 ， 包 括 读 和 写 ， 而 由 于 
Android 系 统 基于 Linux， 使 得 其 并 发 读 / 写 文件 可 以 没有 限制 地 进行 ， 
甚至 两 个 线程 同时 对 同一 个 文件 进行 写 操作 都 是 允许 的 ， 尽 管 这 可 能 
出 问题 。 通 过 文件 交换 数据 很 好 使 用 ， 除 了 可 以 交换 一 些 文本 信息 
外 ， 我 们 还 可 以 序列 化 一 个 对 象 到 文件 系统 中 的 同时 从 另 一 个 进程 中 
恢复 这 个 对 象 ， 下 面 惑 展示 这 种 使 用 方法 。 


还 是 本 章 刚 开始 的 那个 例子 ， 这 次 我 们 在 MainActivity 的 
onResume 中 序列 化 一 个 User 对 象 到 sd 卡 上 的 一 个 文件 里 ， 然 后 在 
SecondActivity 的 onResume 中 去 反 序 列 化， 我 们 期 望 在 SecondActivity 
中 能 够 正确 地 恢复 User 对 象 的 值 。 关 键 代 码 如 下 : 


下 面 看 一 下 log， 很 显然 ， 在 SecondActivity 中 成 功 地 从 文件 从 恢复 
了 之 前 存储 的 User 对 象 的 内 容 ， 这 里 之 所 以 说 内 容 ， 是 因为 反 序列 化 
得 到 的 对 象 只 是 在 内 容 上 和 序列 化 之 前 的 对 象 是 一 样 的 ， 但 它们 本 质 
上 还 是 两 个 对 象 。 


D/SecondActivity(10877): recover user:User: 
{userId:1,userName:hello world, 


isMale:false},with child: {null} 


EB a SC AE ER RT AR EY OC PAG EI BAR BK 
的 ， 比 如 可 以 是 文本 文件 ， 也 可 以 是 XML 文件 ， 只 要 读 / 写 双 方 约定 数 
据 格 式 即 可 。 通 过 文件 共 束 的 方式 也 是 有 局 限 性 的 ， 比 如 并 发 读 / 写 的 
问题 ， 像 上 面 的 那个 例子 ， 如 采 并 发 读 / 写 ， 那 么 我 们 读 出 的 内 容 丈 有 
可 能 不 是 最 新 的 ， 如 果 是 并 发 写 的 话 那 承 更 严重 了 。 因 此 我 们 要 尽量 
避免 并 发 写 这 种 情况 的 发 生 或 者 考虑 使 用 线程 同步 来 限制 多 个 线程 的 
写 操作 。 通 过 上 面 的 分 析 ， 我 们 可 以 知道 ， 文 件 共享 方式 适合 在 对 数 
据 同 步 有 要 求 不 高 的 进程 之 间 进 行 通信 ， 并 且 要 有 善 处 理 并 发 读 / 写 的 问 


题 。 


当然 ，SharedPreferences 是 个 特例 ， 众 所 周知 ，SharedPreferences 
是 Android 中 提供 的 轻 量 级 存储 方案 ， 它 通过 键 值 对 的 方式 来 存储 数 
据 ， 在 底层 实现 上 它 采 用 XML 文件 来 存储 键 值 对 ， 每 个 应 用 的 
SharedPreferences 文 件 都 可 以 在 当前 包 所 在 的 data 目 录 下 查看 到 。 一 般 
来 说 ， 它 的 目 孙 位 于 /data/data/package name/shared_prefs 目 孙 下 ， 其 中 
package name 表示 的 是 当前 应 用 的 包 和 名 。 从 本 质 上 来 说 ， 
SharedPreferences 也 属于 文件 的 一 种 ， 但 是 由 于 系统 对 它 的 读 / 写 有 一 
定 的 缓存 策略 ， 即 在 内 存 中 会 有 一 份 SharedPreferences 文 件 的 缓存 ， 
此 在 多 进程 模式 下 ， 系 统 对 它 的 读 / 写 承 变 得 不 可 靠 ， 当 面 对 高 并 发 的 
读 / 写 访问 ，Sharedpreferences 有 很 大 几率 会 丢失 数据 ， 因 此 ， 不 建议 
在 进程 间 通 信 中 使 用 SharedPreferences。 


2.4.3 ”使 用 Messenger 


Messenger) 以 翻译 为 信使 ， 顾 名 思 义 ， 通 过 它 可 以 在 不 同 进程 中 
传递 Message 对 象 ， 在 Message 中 放 入 我 们 需要 传递 的 数据 ， 残 可 以 轻 
松 地 实现 数据 的 进程 间 传递 了 。Messenger 是 一 种 轻 量 级 的 IPC 方 案 ， 
它 的 底层 实现 是 AIDL ， 为 什么 这 么 说 昵 ， 我 们 大 致 看 一 下 Messenger 
这 个 类 的 构造 方法 就 明白 了 。 下 面 是 Messenger 的 两 个 构造 方法 ， 从 构 
造 方法 的 实现 上 我 们 可 以 明显 看 出 AIDL 的 痕迹 ， 不 管 是 IMessengerj 还 
是 Stub.asInterface， 这 种 使 用 方法 都 表明 它 的 底层 是 AIDL 。 


public Messenger(Handler target) { 
mTarget = target.getIMessenger(); 

} 

public Messenger (IBinder target) { 


mTarget = IMessenger.Stub.asInterface(target); 


} 


Messenger 的 使 用 方法 很 简单 ， 它 对 AIDL 做 了 封装 ， 使 得 我 们 可 
以 更 简便 地 进行 进程 间 通 信 。 同 时 ， 由 于 它 一 次 处 理 一 个 请 求 ， 因 此 
在 服务 端 我 们 不 用 考虑 线程 同步 的 问题 ， 这 是 因为 服务 端 中 不 存在 并 
发 执行 的 情形 。 实 现 一 个 Messenger 有 如 下 几 个 步骤 ， 分 为 服务 端 和 窗 
户 端 。 


1. 服务 端 进程 


首先 ， 我 们 需要 在 服务 端 创建 一 个 Service 来 处 理 客户 端的 连接 请 
求 ， 同 时 创建 一 个 Handler 并 通过 它 来 创建 一 个 Messenger 对 象 ， 然 后 
在 Service 的 onBind 中 返回 这 个 Messenger 对 象 底 层 的 Binder 即 可 > 


2. 客户 端 进程 


Pum, HATE RS A Service, WERD a HARIS 
Wa WL [Bl AY IBinder xy & 813 — Messenger, IL Messenger A] LA 
问 服 务 端 发 送 消 息 了 ， 发 消息 类 型 为 Message 对 象 。 如 采 需 要 服务 端 能 
够 回应 客户 端 ， 就 和 服务 端 一 样 ， 我 们 还 需要 创建 一 个 Handler 并 创建 
一 个 新 的 Messenger， 并 把 这 个 Messenger 对 象 通 过 Message 的 replyTo 参 
数 传递 给 服务 端 ， 服 务 端 通 过 这 个 replyTo 参 数 葡 可 以 回应 客户 端 。 这 
听 起 来 可 能 还 是 有 点 抽象 ， 不 过 看 了 下 面 的 两 个 例子 ， 读 者 肯定 残 都 
明 晶 了。 首先， 我 们 来 看 一 个 简单 点 的 例子 ， 在 这 个 例子 中 服务 端 无 
法 回应 客户 端 。 


首先 看 服务 端的 代码 ， 这 是 服务 端 隐 典 型 代码 ， 可 以 看 到 
MessengerHandler 用 来 处 理 客 户 端 发 送 的 消 思 ， 并 从 消息 中 取出 客户 
端 发 来 的 文本 信息 。 而 mMessenger 是 一 个 Messenger 对 象 ， 它 和 
MessengerHandler 相 关联 ， 并 在 onBind 方 法 中 返回 它 里 面 的 Binder 对 
象 ， 可 以 看 出 ， 这 里 Messenger 的 作用 是 将 客户 端 发 送 的 消息 传递 给 
MessengerHandler 处 理 。 


public class MessengerService extends Service { 
private static final String TAG = "MessengerService"; 


private static class MessengerHandler extends Handler 


@Override 
public void handleMessage (Message msg) { 
switch (msg.what) { 
case MyConstants.MSG_FROM_CLIENT: 
Log.i(TAG, "receive msg from Client:" + 


msg.getData(). 


然后 ， 注 册 service， 让 其 运行 在 单独 的 进程 中 : 


接 下 来 再 看 看 客户 端的 实现 ， 客 户 端的 实现 也 比较 简单 ， 首 移 需 
要 绑 定 远程 进程 的 MessengerService， 绑 定 成 功 后 ， 根 据 服务 端 返回 的 
binder 对 象 创 建 Messenger 对 象 并 使 用 此 对 象 向 服务 端 发 送 消 妃 。 下 面 
的 代码 在 Bundle 中 辐 服 务 端 发 送 了 一 句 话 ， 在 上 面 的 服务 端 代码 中 会 
打印 出 这 句 话 。 


super .onCreate(savedInstanceState); 
setContentView(R.layout.activity_messenger); 
Intent intent = new 


Intent(this,MessengerService.class); 


bindService(intent,mConnection, Context.BIND_AUTO_CREATE); 
} 
@Override 
protected void onDestroy() { 
unbindService(mConnection) ; 


super .onDestroy(); 


} 


最 后 ， 我 们 运行 程序 ， 看 一 下 log， 很 显然 ， 服 务 端 成 功 收 到 了 客 
户 端 所 发 来 的 问候 语 : “hello,this is client.” ° 


I/MessengerService( 1037): receive msg from 


Client:hello,this is client. 


通过 上 面 的 例子 可 以 看 出 ， 在 Messenger 中 进行 数据 传递 必须 将 数 
据 放 入 Message 中 ， 而 Messenger 和 Message 都 实现 了 Parcelable 接 口 ， 
此 可 以 跨 进 程 传输 。 简 单 来 说 ，Message 中 所 支持 的 数据 类 型 就 是 
Messenger 所 文 持 的 传输 类 型 。 实 际 上 ， 通 过 Messenger 来 传输 
Message，Message 中 能 使 用 的 载体 只 有 what、arg1、arg2、Bundle 以 及 
replyTo。Message 中 的 另 一 个 字段 object 在 同一 个 进程 中 是 很 实用 的 ， 
但 是 在 进程 间 通 信 的 时 候 ， 在 Android 2.2 以 前 object 字 上 段 不 支持 跨 进 程 
传输 ， 即 便 是 2.2 以 后 ， 也 仅仅 是 系统 提供 的 实现 了 Parcelable 接 口 的 对 
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通过 object 字 段 来 传输 的 ， 读 者 可 以 试 一 下 。 非 系统 的 Parcelable 对 象 
的 确 无 法 通过 object 字 段 来 传输 ， 这 也 导致 了 object 字 段 的 实用 性 大 大 
降低 ， 所 笠 我 们 还 有 Bundle，Bundle 中 可 以 支持 大 量 的 数据 类 型 o 


上 面 的 例子 演示 了 如 何在 服务 端 接 收 客户 端 中 发 送 的 消 轧 ， 但 是 
有 时 候 我 们 还 需要 能 回应 客户 端 ， 下 面 束 介 绍 如 何 实现 这 种 效果 < 还 
苹 采 用 上 面 的 例子 ,但 古称 微 做 一 下 修改 ， 每 当 客 户 端 发 来 一 条 消 
思 ， 有 上 服务 端 束 会 目 动 回 复 一 条 “ 咀 ， 你 的 消 妃 我 已 经 收 到 ， 稍 后 会 回复 
你 。”， 这 很 类 似 邮 箱 的 目 动 回复 功能 


自 先 看 服务 端的 修改 ， 服 务 端 只 需要 修改 MessengerHandler， 当 
收 到 消息 后 ， 会 立即 回复 一 条 消息 给 客户 端 。 


private static class MessengerHandler extends Handler { 
@Override 
public void handleMessage (Message msg) { 
switch (msg.what) { 
case MyConstants.MSG_FROM_CLIENT: 
Log.i(TAG, "receive msg from Client:" + 
msg.getData().getString 
("msg") ); 
Messenger client = msg.replyTo; 
Message relpyMessage = 
Message. obtain(null,MyConstants.MSG_ 
FROM_SERVICE) ; 
Bundle bundle = new Bundle(); 
bundle.putString("reply", "TA, (RAH BIE AEI, 


接着 再 看 客户 端的 修改 ， 为 了 接收 服务 端的 回复 ， 客 户 端 也 需要 
准备 一 个 接收 消息 的 Messenger 和 Handler， 如 下 所 示 。 


RT bA, DABA A, KR PRAIA ATRAE, 
需要 把 接收 服务 端 回复 的 Messenger 通 过 Message 的 replyTo 参 数 传递 给 
服务 端 ， 如 下 所 示 。 


通过 上 述 修改 ， 我 们 再 运行 程序 ， 然 后 看 一 人 log， 很 显然 ， 客 户 
Jo WE TARA E RR OE, ES 


你 。”， 这 说 明 我 们 的 功能 已 经 完成 。 


I/MessengerService( 1419): receive msg from 
Client:hello,this is client. 
I/MessengerActivity( 1404): receive msg from Service: A, 4% 


的 消息 我 已 经 收 到 ， 稍 后 会 回复 你 。 


到 这 里 ， 我 们 已 oil 绍 
完了 ， 读 者 可 以 试 着 通过 Messenger 来 实现 更 复杂 的 跨 进程 通信 功能 
下 面 给 出 一 张 Messenger 的 工作 原理 图 以 方便 读者 更 好 地 理解 
Messenger， 如 图 2-6 所 示 。 


Messen ger 
Message > 
Binder 3 
Client | Service 


replyTo Messenger 
< <——~ Message A~ 


 Binder 


Handler | 


图 2-6” Messenger 的 工作 原理 


天 于 进程 间 通 信 ， 可 能 有 的 读者 会 觉得 笔者 提供 的 示例 都 是 针对 
同一 个 应 用 的 ， 有 没有 针对 不 同 应 用 的 ? 是 这 样 的 ， 之 所 以 选择 在 同 
一 个 应 用 内 进行 进程 间 通 信 ， 是 因为 操作 起 来 比较 方便 ， 但 是 效果 和 
在 两 个 应 用 间 进 行进 程 间 通信 十 一 样 的 。 在 本 章 刚 开始 殉 说 过 ， 同 一 
个 应 用 的 不 同 组 件 ， 如 采 它 们 运行 在 不 同 进程 中 ， 那 么 和 它们 分 别 属 
于 两 个 应 用 没有 本 质 区 别 ， 关 于 这 点 需要 深刻 理解 ， 因 为 这 是 理解 进 
程 间 通信 的 基础 。 


2.4.4 ”使 用 AIDL 


上 一 市 我 们 介绍 了 使 用 Messenger 来 进行 进程 间 通 信 有 的 方法 ， 可 以 
发 现 ，Messenger 是 以 串 行 的 方式 处 理 客 户 端 发 来 的 消息 ， 如 果 大 量 的 
消息 同时 发 送 到 服务 端 ， 服 务 端 仍然 只 能 一 个 个 处 理 ， 如 果 有 大 量 的 
并 发 请 求 ， 那 么 用 Messenger 束 不 太 合适 了 。 同 时 ，Messenger 的 作用 
主要 是 为 了 传递 消息 ， 很 多 时 候 我 们 可 能 需要 跨 进 程 调用 服务 端的 方 
法 ， 这 种 情形 用 Messenger 就 无 法 做 到 了 ， 但 是 我 们 可 以 使 用 AIDL 来 
实现 跨 进 程 的 方法 调用 。AIDL 也 是 Messenger 的 底层 实现 ， 因 此 
Messenger 本 质 上 也 是 AIDL ， 只 不 过 系统 为 我 们 做 了 封装 从 而 方便 上 
层 的 调用 而 已 。 在 上 一 市 中 ， 我 们 介绍 了 Binder 的 概念 ， 大 家 对 Binder 
也 有 了 一 定 的 了 解 ， 在 Binder 的 基础 上 我 们 可 以 更 加 容易 地 理解 
AIDL。 这 里 移 介 绍 使 用 AIDL 来 进行 进程 间 通 信 的 流程 ， 分 为 服务 端 
和 窗户 端 两 个 方面 。 


1. 服务 端 


服务 端 首先 要 创建 一 个 Service 用 来 监听 客户 端的 连接 请 求 ， 然 后 
创建 一 个 AIDL 文 件 ， 将 又 露 给 客户 端的 接口 在 这 个 AIDL 文 件 中 声 
明 ， 最 后 在 Service 中 实现 这 个 AIDL 接 口 即 可 。 


2. 客户 端 


客户 端 所 要 做 事情 惑 稍 微 简 单一 些 ， 首 移 需 要 绑 定 服务 端的 
Service， 绑 定 成 功 后 ， 将 服务 端 返 回 的 Binder 对 象 转 成 AIDL 接 口 所 属 
的 类 型 ， 接 着 就 可 以 调用 AIDL 中 的 方法 了 。 


上 面 描述 的 只 是 一 个 感性 的 过 程 ，AIDL 的 实现 过 程 远 不 止 这 么 简 
单 ， 接 下 来 会 对 其 中 的 细节 和 难点 进行 详细 介绍 ， 并 完善 我 们 在 
Binder 那 一 广 所 提供 的 的 实例 。 


3. AIDL 接 口 的 创建 


目 先 看 AIDL 接 口 的 创建 ， 如 下 所 示 ， 我 们 创建 了 一 个 后 缀 为 
AIDL 的 文件 ， 在 里 面 声明 了 一 个 接口 和 两 个 接口 方法 。 


// IBookManager .aidl 

package com.ryg.chapter_2.aidl; 

import com.ryg.chapter_2.aidl.Book; 

interface IBookManager { 
List<Book> getBookList(); 
void addBook(in Book book); 

+) 


在 AIDL 文 件 中 ， 并 不 是 所 有 的 数据 类 型 都 是 可 以 使 用 的 ， 那 么 到 
底 AIDL 文 件 支持 哪些 数据 类 型 呢 ? 如 下 所 示 。 


基本 数据 类 型 (int、long、char、boolean、double 等 ) ; 
String 和 CharSequence:; 

e List: 只 文 持 ArrayList， 里 面 每 个 元 素 都 必须 能 够 被 AIDL 文 持 ; 

e Map: 只 文 持 HashMap， 里 面 的 每 个 元 素 都 必须 被 AIDL 文 持 ， 包 
括 key 和 value; 

Parcelable: 所 有 实现 了 Parcelable 接 口 的 对 象 

AIDL: 所 有 的 AIDL 接 口 本 身 也 可 以 在 AIDL 文 件 中 使 用 。 


以 上 6 种 数据 类 型 加 是 AIDL 所 文 持 的 所 有 类 型 ， 其 中 上 自 定 义 的 
Parcelable 对 象 和 AIDL 对 象 必须 要 显 式 import 进 来 ， 不 管 它们 是 否 和 当 
前 的 AIDL 文 件 位 于 同一 个 包 内 。 比 如 IBookManager.aidl 这 个 文件 ， 里 
面 用 到 了 Book 这 个 类 ， 这 个 类 实现 了 Parcelable 接 口 并 且 和 
IBookManageraidl 位 于 同一 个 包 中 ， 但 是 遵守 AIDL 的 规范 ， 我 们 仍然 
需要 显 式 地 import 进 来 : import com.ryg.chapter_2.aidl.Book ° AIDL "F 
会 大 量 使 用 到 Parcelable， 至 于 如 何 使 用 Parcelable 接 口 来 序列 化 对 象 ， 
在 本 划 的 前 面 已 经 介绍 过 ， 这 里 就 不 再 著述 。 


另外 一 个 需要 注意 的 地 方 是 ， 如 果 AIDL 文 件 中 用 到 了 目 定 义 的 
Parcelable 对 象 ， 那 么 必须 新 建 一 个 和 它 同 名 的 AIDL 文 件 ， 并 在 其 中 
声明 它 为 Parcelable 类 型 。 在 上 面 的 IBookManageraidl 中 ， 我 们 用 到 了 
Book 这 个 类 ， 所 以 ， 我 们 必须 要 创建 Book.aidl ， 然 后 在 里 面 添 加 如 下 


AZ: 


package com.ryg.chapter_2.aidl; 


parcelable Book; 


我 们 需要 注意 ，AIDL 中 每 个 实现 了 Parcelable 接 口 的 类 都 需要 按 
照 上 面 那 种 方式 去 创建 相应 的 AIDL 文 件 并 声明 那个 类 为 parcelable。 除 
此 之 外 ，AIDL 中 除了 基本 数据 类 型 ， 其 他 类 型 的 参数 必须 标 上 方 问 : 
in、out 或 者 inout，in 表 示 输 入 型 参数 ，out 表 示 输 出 型 参数 ，inout 表 示 
输入 输出 型 参数 ， 至 于 它们 具体 的 区 别 ， 这 个 就 不 说 了 。 我 们 要 根据 
实际 需要 去 指定 参数 类 型 ， 不 能 一 概 使 用 out 或 者 inout， 因 为 这 在 确 层 
实现 是 有 开销 的 。 最 后 ，AIDL 接 口中 只 文 持 方法 ， 不 文 持 声 明 静 态 常 
量 ， 这 一 点 区 别 于 传统 的 接口 。 


为 了 方便 AIDL 的 开发 ， 建 议 把 所 有 和 AIDL 相 关 的 类 和 文件 全 前 
放 入 同一 个 包 中 ， 这 样 做 的 好 处 是 ， 当 客户 端 是 男 外 一 个 应 用 时 ， 我 
们 可 以 直接 把 整个 包 复制 到 客户 端 工 程 中 ， 对 于 本 例 来 说 ， 就 是 要 把 
com.ryg.chapter_2.aidl 这 个 包 和 包 中 的 文件 原封 不 动 地 复制 到 客户 端 
中 。 如 果 AIDL 相 关 的 文件 位 于 不 同 的 包 中 时 ， 那 么 就 需要 把 这 些 包 一 
一 复制 到 客户 端 工程 中 ， 这 样 操作 起 来 比较 据 烦 而 且 也 容易 出 错 。 需 
要 注意 的 是 ，AIDL 的 包 结 构 在 服务 端 和 客户 端 要 保持 一 致 ， 否 则 运行 
会 出 错 ， 这 是 因为 客户 端 需 要 反 序列 化 服务 端 中 和 AIDL 接 口 相关 的 所 
有 类 ， 如 果 类 的 完整 路 径 不 一 样 的 话 ， 职 无 法 成 功 反 序列 化 ， 程 序 也 
残 无 法 正 弟 运行 。 为 了 方便 演示 ， 本 章 的 所 有 示例 都 是 在 同一 个 工程 
中 进行 的 ， 但 是 读者 要 理解 ， 一 个 工程 和 两 个 工程 的 多 进程 本 质 是 一 
样 的 ， 两 个 工程 的 情况 ， 除 了 需要 复制 AIDL 接 口 所 相关 的 包 到 客户 
端 ， 其 他 完全 一 样 ， 读 者 可 以 自行 试验 。 


4. 远程 服务 端 Service 的 实现 


上 面 讲述 了 如 何 定义 AIDL 接 口 ， 接 下 来 我 们 融 需 要 实现 这 个 接口 
了 。 我 们 先 创 建 一 个 Service， 称 为 BookManagerService， 代 码 如 下 : 


public class BookManagerService extends Service { 

private static final String TAG = "BMS"; 

private CopyOnwriteArrayList<Book> mBookList = new 
CopyOnwriteArray- 

List<Book>(); 

private Binder mBinder = new IBookManager.Stub() { 
@Override 

public List<Book> getBookList() throws 


RemoteException { 


上 面 是 一 个 服务 端 Service 的 典型 实现 ， 首 移 在 onCreate 中 初始 化 
添加 了 两 本 图 书 的 信息 ， 然 后 创建 了 一 个 Binder 对 象 并 在 onBind 中 返 
回 它 ， 这 个 对 象 继 承 自 IBookManager.Stub 并 实现 了 它 内 部 的 AIDL 方 
法 ， 这 个 过 程 在 Binder 那 一 市 已 经 介绍 过 了 ， 这 里 就 不 多 说 了 。 这 里 
主要 看 getBookList 和 addBook 这 两 个 AIDL 方 法 的 实现 ， 实 现 过 程 也 比 
较 简 单 ， 注 意 这 里 采用 了 CopyoOonwriteArrayList ， 这 个 
CopyOnWriteArrayList 文 持 并 发 读 / 写 。 在 前 面 我 们 提 到 ，AIDL 方 法 是 


在 服务 端的 Binder 线 程 池 中 执行 的 ， 因 此 当 多 个 客户 端 同时 连接 的 时 
候 ， 会 存在 多 个 线程 同时 访问 的 情形 ， 所 以 我 们 要 在 AIDL 方 法 中 处 理 
线程 同步 ， 而 我 们 这 里 直接 使 用 CopyOnWriteArrayList 来 进行 目 动 的 线 
程 同 步 。 


前 面 我 们 提 到 ，AIDL 中 能 够 使 用 的 List 只 有 ArrayList， 但 是 我 们 
这 里 却 使 用 了 CopyOnWriteArrayList (注意 它 不 是 继承 自 ArrayList) , 
为 什么 能 够 正常 工作 呢 ? 这 是 因为 AIDL 中 所 支持 的 是 抽象 的 List， 而 
List 只 是 一 个 接口 ， 因 此 虽然 服务 端 返回 的 是 CopyOnWriteArrayList， 
但 是 在 Binder 中 会 按照 List 的 规范 去 访问 数据 并 最 终 形成 一 个 新 的 
ArrayList 传递 给 客户 端 。 所 以 ， 我 们 在 服务 端 采 用 
CopyOnWriteArrayList 是 完全 可 以 的 。 和 此 类 似 的 还 有 
ConcurrentHashMap ， 读 者 可 以 体会 一 下 这 种 转换 情形 。 然 后 我 们 需要 
在 XML 中 注册 这 个 Service， 如 下 所 示 。 注 意 BookManagerService 是 运 
行 在 独立 进程 中 的 ， 它 和 客户 端的 Activity 不 在 同一 个 进程 中 ， 这 样 吏 
构成 了 进程 间 通 信 的 场景 。 


<service 
android:name=".aidl.BookManagerService" 
android:process=":remote" > 


</service> 
5. 客户 端的 实现 


客户 端的 实现 束 比 较 人 简单 了 ， 首 先 要 缕 定 远程 服务 ， 缘 定 成 功 后 
将 服务 端 返回 的 Binder 对 象 转换 成 AIDL 接 口 ， 然 后 就 可 以 通过 这 个 接 
口 去 调用 服务 端的 远程 方法 了 ， 代 码 如 下 所 示 。 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_book_manager); 
Intent intent = new 


Intent(this,BookManagerService.class); 


bindService(intent,mConnection,Context.BIND_AUTO_CREATE); 
} 
@Override 
protected void onDestroy() { 
unbindService(mConnection) ; 


super .onDestroy(); 


绑 定 成 功 以 后 ， 会 通过 bookManager 去 调用 getBookList 方 法 ， 然 
打印 出 所 获取 的 图 书信 息 。 需 要 注意 的 是 ， 服 务 端 的 方法 有 可 能 需 
很 久 才能 执行 完毕 ， 这 人 1 A 会 导致 ANR， 这 一 点 是 需 
要 注意 的 ， 后 面 会 再 介绍 这 种 情况 ， 之 所 以 先 这 么 写 是 为 了 让 读者 更 
好 地 了 解 AIDL 的 实现 步 又。 


EE 


接着 在 XML 中 注册 此 Activity， 运 行程 序 ，log 如 下 所 示 。 


I/BookManagerActivity(3047): query book list, list 
type:java.util.ArrayList 
I/BookManagerActivity(3047): query book list: 


[[bookId:1,bookName: Android], [bookId:2,bokName: Ios] ] 


可 以 发 现 ， 虽 然 我 们 在 服务 端 返回 的 是 CopyOnWriteArrayList 类 
型 ， 但 是 客户 端 收 到 的 仍然 是 ArrayList 类 型 ， 这 也 证 实 了 我 们 在 前 面 


所 做 的 分 析 。 第 二 行 log 表 明 客 户 剖 成 功 地 得 到 了 服务 端的 图 书 列表 信 
E 


¿DD 


这 就 是 一 次 完 完整 整 的 使 用 AIDL 进 行 IPC 的 过 程 ， 到 这 里 相信 读 
a 了 ， 但 是 还 没完 ，AIDL 的 复杂 性 
远 不 止 这 些 ， 下 面 继续 介绍 AIDL 中 常见 的 一 些 难 点 


我 们 接着 再 调用 一 下 另外 一 个 接口 addBook， 我 们 在 客户 端 给 服 
务 端 添 加 一 本 书 ， 然 后 再 获取 一 次 ， 看 程序 是 否 能 够 正常 工作 。 还 是 
上 面 的 代码 ， 客 户 端 在 服务 连接 后 ， 在 onServiceConnected 中 做 如 下 改 
Z): 


public void onServiceConnected(ComponentName 
className, IBinder service) { 
IBookManager bookManager = 
IBookManager .Stub.asInterface(service); 
try { 
List<Book> list = bookManager .getBookList(); 
Log.i(TAG, "query book list:" + 
list.toString()); 
Book newBook = new Book(3,"Android 开 发 艺术 探索 " ) ， 
bookManager .addBook(newBook) ; 
Log.i(TAG, "add book:" + newBook ) ; 
List<Book> newList = bookManager .getBookList(); 
Log.i(TAG, "query book list:" + 


newList.toString()); 


} catch (RemoteException e) { 


e.printStackTrace(); 


} 


运行 后 我 们 再 看 一 下 log， 很 显然 ， 我 们 成 功 地 回 服 务 端 添 加 了 一 
本 书 “Android 开 发 艺术 探索 ”。 


I/BookManagerActivity( 3148): query book list: 
[[bookId:1,bookName: Android], [bookId:2,bookName:Ios]] 
I/BookManagerActivity( 3148): add book: 
[bookId: 3, bookName :AndroidF X 211%] 
I/BookManagerActivity( 3148): query book list: 
[[booKId:1,bookName:Android], [bookId:2,bookName: Ios], 
[bookId:3, bookName:AndroidF 221%] ] 


现在 我 们 考虑 一 种 情况 ， 假 设 有 一 种 需求 : 用 户 不 想 时 不 时 地 去 
查询 图 书 列表 了 ， 太 累 了， 于 是 ， 他 去 问 图 书馆 ，“ 当 有 新 书 时 能 不 能 
把 书 的 信息 告诉 我 呢 ?”。 大 家 应 该 明白 了 ， 这 就 是 一 种 典型 的 观察 者 
模式 ， 每 个 感 兴 趣 的 用 户 都 观察 新 书 ， 当 新 书 到 的 时 候 ， 图 书馆 就 通 
知 每 一 个 对 这 本 书 感 兴趣 的 用 户 ， 这 种 模式 在 实际 开发 中 用 得 很 多 ， 
下 面 我 们 就 来 模拟 这 种 情形 。 首 先 ， 我 们 需要 提供 一 个 AIDL 接 口 ， 
个 用 户 都 需要 实现 这 个 接口 并 且 回 图 书馆 申请 新 书 的 提醒 功能 ， 当 然 
用 户 也 可 以 随时 取消 这 种 提醒 。 之 所 以 选择 AIDL 接 口 而 不 是 普通 接 
口 ， 是 因为 AIDL 中 无 法 使 用 普通 接口 。 这 里 我 们 创建 一 个 
IOnNewBookArrivedListeneraidl 文 件 ， 我 们 所 期 望 的 情况 是 : 当 服 务 
端 有 新 书 到 来 时 ， 束 会 通知 每 一 个 已 经 申请 提醒 功能 的 用 户 。 从 程序 
上 来 说 就 是 调用 所 有 IOnNew BookArrivedListener 对 象 中 的 


onNewBookArrived 方 法 ， 并 把 新 书 的 对 象 通过 参数 传递 给 客户 端 ， 内 
容 如 下 所 示 。 


package com.ryg.chapter_2.aidl; 
import com.ryg.chapter_2.aidl.Book; 
interface IOnNewBookArrivedListener { 


void onNewBookArrived(in Book newBook); 


除了 要 新 加 一 个 AIDL 接 口 ， 还 需要 在 原 有 的 接口 中 添加 两 个 新 方 
法 ， 代 码 如 下 所 示 。 


package com.ryg.chapter_2.aidl; 
import com.ryg.chapter_2.aidl.Book; 
import com.ryg.chapter_2.aidl.IOnNewBookArrivedListener; 
interface IBookManager { 
List<Book> getBookList(); 
void addBook(in Book book); 
void registerListener (IOnNewBookArrivedListener 
listener); 
void unregisterListener (IOnNewBookArrivedListener 


listener); 


i 


接着 ， 服 务 端 中 Service 的 实现 也 要 稍微 修改 一 下 ， 主 要 是 Service 
中 IBookManagerStub 的 实现 ， 因 为 我 们 在 IBookManager 新 加 了 两 个 方 
法 ， 所 以 在 IBookManagerStub 中 也 要 实现 这 两 个 方法 。 同 时 ， 在 


BookManagerService 中 还 开局 了 一 个 线程 ， 每 隔 5s 束 回 书 库 中 增加 一 
本 新 书 并 通知 所 有 感 兴趣 的 用 户 ， 整 个 代码 如 下 所 示 。 


最 后 ， 我 们 还 需要 修改 一 下 客户 端的 代码 ， 主 要 有 两 方面 : 首先 
客户 端 要 注册 IOnNewBookArrivedListener 到 远程 服务 端 ， 这 样 当 有 新 


书 时 服务 端 才能 通知 当前 客户 端 ， 同 时 我 们 要 在 Activity 退 出 时 解除 这 
个 注册 ; 另 一 方面 ， 当 有 新 书 时 ， 服 务 端 会 回调 客户 端的 
IOnNewBookArrivedListener 对 象 中 的 onNewBookArrived 方 法 ， 但 是 这 
个 方法 是 在 客户 端的 Binder 线 程 池 中 执行 的 ， 因 此 ， 为 了 便于 进行 UI 
操作 ， 我 们 需要 有 一 个 Handler 可 以 将 其 切换 到 客户 端的 主线 程 中 去 执 
行 ， 这 个 原理 在 Binder 中 已 经 做 了 分 析 ， 这 里 就 不 多 说 了 。 客 户 端的 
代码 修改 如 下 : 


public class BookManagerActivity extends Activity { 
private static final String TAG = 
"BookManagerActivity"; 
private static final int MESSAGE_NEW_BOOK_ARRIVED = 1; 
private IBookManager mRemoteBookManager ; 
private Handler mHandler = new Handler() { 
@Override 
public void handleMessage (Message msg) { 
switch (msg.what) { 
case MESSAGE_NEW_BOOK_ARRIVED: 
Log.d(TAG, "receive new book :" + msg.obj); 
break; 
default: 


super.handleMessage(msg); 


}; 
private ServiceConnection mConnection = new 


ServiceConnection() { 


行程 序 ， 看 一 人 log， 从 log 中 可 以 看 出 ， 客 户 端的 确 收 到 了 服 


运 
务 端 每 5s 一 次 的 新 书 推送 ， 我 们 的 功能 也 就 实现 了 。 


D/BookManagerActivity( 3385): receive new book 
[bookId: 4, bookName: new 
book#4] 
D/BMS(3414) :onNewBookArrived, notify 
listener:com.ryg.chapter_2.aidl. 
IOnNewBookArrivedListener$Stub$Proxy@4052a648 
D/BookManagerActivity( 3385): receive new book 
[bookId:5,bookName :new 


book#5] 


IRAK BUX HAIDLEIST SA A EA 
过 ，AIDL 远 不 止 这 么 人 简单， 目前 还 有 一 些 难 点 古 我 们 还 没有 涉及 的 ， 
接 下 来 将 继续 为 读者 介绍 。 


从 上 面 的 代码 可 以 看 出 ， 当 BookManagerActivity 关 闭 时 ， 我 们 会 
在 onDestroy 中 去 解除 已 经 注册 到 服务 端的 listener， 这 残 相 当 于 我 们 不 
想 再 接收 图 书馆 的 新 书 提醒 了 ， 所 以 我 们 可 以 随时 取消 这 个 提醒 服 
务 。 按 back 键 退出 BookManagerActivity， 下 面 是 打印 出 的 log ° 


I/BookManagerActivity(5642): unregister 
listener:com.ryg.chapter_2.aidl. 
BookManagerActivity$30405284c8 
D/BMS(5650): not found,can not unregister. 


D/BMS(5650): unregisterListener, current size:1 


从 上 面 的 log 可 以 看 出 ， 程 序 没 有 像 我 们 所 预期 的 那样 执行 。 在 解 
注册 的 过 程 中 ， 服 务 端 竟然 无 法 找到 我 们 之 前 注册 的 那个 listener， 在 
客户 端 我 们 注册 和 解 注 册 时 明明 传递 的 是 同一 个 listener 啊 ! 最 终 ， 服 


务 端 由 于 无 法 找到 要 解除 的 listener 而 宣告 解 注册 失败 ! 这 当然 不 是 我 
们 想 要 的 结果 ， 但 是 仔细 想 想 ， 好 像 这 种 方式 的 确 无 法 完成 解 注 册 。 
其 实 ， 这 是 必然 的 ， 这 种 解 注册 的 处 理 方式 在 日 常 开发 过 程 中 时 常 使 
用 到 ,但 是 放 到 多 进程 中 却 无 法 奏效 ， 因 为 Binder 会 把 客户 端 传递 过 
来 的 对 象 重 新 转化 并 生成 一 个 新 的 对 象 。 昌 然 我 们 在 注册 和 人 解 注册 过 
程 中 使 用 的 是 同一 个 客户 端 对 象 ， 但 是 通过 Binder 传 递 到 服务 端 后 ， 
却 会 产生 两 个 全 新 的 对 象 。 别 专 了 对 象 是 不 能 跨 进 程 直接 传输 的 ， 对 
象 的 跨 进 程 传输 本 质 上 都 是 反 序 列 化 的 过 程 ， 这 就 是 为 什么 AIDL 中 的 
目 定 义 对 象 都 必须 要 实现 Parcelable 接 口 的 原因 。 那 么 到 底 我 们 该 怎么 
做 才能 实现 解 注册 功能 呢 ? 答案 是 使 用 RemoteCallbackList， 这 看 起 来 
很 抽象 ， 不 过 没关系 ， 请 看 接 下 来 的 详细 分 析 。 


RemoteCallbackList 是 系统 专门 提供 的 用 于 删除 器 进程 listener 的 接 
口 。Remote-CallbackList 是 一 个 泛 型 ， 文 持 管 理 任 意 的 AIDL 接 口 ， 这 
点 从 它 的 声明 就 可 以 看 出 ， 因 为 所 有 的 AIDL 接 口 都 继承 目 IInterface 接 
口 ， 读 者 还 有 印象 吗 ? 


public class RemoteCallbackList<E extends IInterface> 


它 的 工作 原 ae 在 它 的 内 部 有 一 个 Map 结 构 专 门 用 来 保存 
所 有 的 AIDL 回 调 ， 这 个 Map 的 key 是 IBinder 类 型 value Callback% 
型 ， 如 下 所 示 。 


ArrayMap<IBinder,Callback> mCallbacks = new 


ArrayMap<IBinder, Callback>(); 


其 中 Callback 中 封装 了 真正 的 远程 listener。 当 客户 端 注 册 listener 的 
时 候 ， 它 会 把 这 个 listener 的 信息 存 和 人 mCallbacks 中 ， 其 中 key 和 value 分 


别 通过 下 面 的 方式 获得 : 


IBinder key= listener.asBinder() 


Callback value = new Callback(listener, cookie) 


到 这 里 ， 读 者 应 该 都 明日 了 ， 虽 然 说 多 次 跨 进 程 传输 客户 端的 同 
一 个 对 象 会 在 服务 端 生 成 不 同 的 对 象 ， 但 是 这 些 新 生成 的 对 象 有 一 个 
共同 点 ， 那 就 是 它们 搬 层 的 Binder 对 象 是 同一 个 ， 利 用 这 个 特性 ， 职 
可 以 实现 上 面 我 们 无 法 实现 的 功能 。 当 客户 端 解 注 册 的 时 候 ， 我 们 只 
要 通 历 服务 端 所 有 的 listener， 找 出 那个 和 解 注册 listener 具 有 相同 
Binder X 3 AY AR % Yi listener FEN HET, Me 
RemoteCallbackList 为 我 们 做 的 事情 。 同 时 RemoteCallbackList 不 有 一 个 
很 有 用 的 功能 ， 那 瓯 是 当 客 户 端 进程 终止 后 ， 它 能 够 目 动 移 除 客户 端 
所 注册 的 listener。 另 外 ，RemoteCallbackList 内 部 目 动 实 现 了 线程 同步 
的 功能 ， 所 以 我 们 使 用 它 来 注册 和 人 解 注册 时 ， 不 需要 做 额外 的 线程 同 
步 工作 。 由 此 可 见 ，RemoteCallbackList 的 确 是 个 很 有 价值 的 类 ， 下 面 
束 演 示 如 何 使 用 它 来 完成 解 注 册 。 


RemoteCallbackList 使 H #2 X R fel A, KR N BW 
BookManagerService 做 一 些 修改 ， 首 先 要 创建 一 个 RemoteCallbackList 
对 象 来 蔡 代 之 前 的 CopyOnWriteArrayList， 如 下 所 示 。 


private RemoteCallbackList<IOnNewBookArrivedListener> 
mListenerList = new 


RemoteCallbackList<IOnNewBookArrivedListener>(); 


然后 修改 registerListener 和 unregisterListener 这 两 个 接口 的 实现 ， 
如 下 所 示 。 


怎么 样 ? 是 不 是 用 起 来 很 答 单 ， 接 着 要 修改 onNewBookArrived 方 


法 ， 当 有 新 书 时 ， 我 们 就 要 通知 所 有 已 注册 的 listener， 如 下 所 示 。 


e.printStackTrace(); 


} 


mListenerList.finishBroadcast(); 


} 


BookManagerService 的 修改 已 经 完毕 了 ， 为 了 方便 我 们 验证 程序 
的 功能 ， 我 们 还 需要 添加 一 些 log， 在 注册 和 解 注 册 后 我 们 分 别 打印 出 
所 有 1listener 的 数量 。 如 果 程 序 正 常 工作 的 话 ， 那 么 注册 之 后 listener 总 
数量 是 1， 解 注册 之 后 总 数量 应 该 是 0， 我 们 再 次 运行 一 下 程序 ， 看 是 
否 如 此 。 从 下 面 的 log 来 看 ， 很 显然 ， 使 用 RemoteCallbackList 的 确 可 以 
完成 跨 进 程 的 解 注 册 功 能 。 


I/BookManagerActivity(8419): register 
listener:com.ryg.chapter_2.aidl. 
BookManagerActivity$3@40537610 
D/BMS(8427): registerListener,current size:1 
I/BookManagerActivity(8419): unregister 
listener:com.ryg.chapter_2.aidl. 
BookManagerActivity$3@40537610 
D/BMS(8427): unregister success. 


D/BMS(8427): unregisterListener, current size:0 


使 用 RemoteCallbackList， 有 一 点 需要 注意 ， 我 们 无 法 像 操 作 List 
一 样 去 操作 它 ， 尽 管 它 的 名 字 中 也 带 个 List， 但 是 它 并 不 是 一 个 List。 
遍历 RemoteCallbackList ， 必 须要 按照 下 面 的 方式 进行 ， 其 中 


beginBroadcast 和 beginBroadcast 必 须要 配对 使 用 ， 哪 怕 我 们 仅仅 是 想 要 
获取 RemoteCallbackList 中 的 元 素 个 数 ， 这 是 必须 要 注意 的 地 方 。 


final int N = mListenerList.beginBroadcast(); 
Tor (aime dd are 
IOnNewBookArrivedListener 1 = 
mListenerList.getBroadcastItem(i); 
if (1 != null) { 
//TODO handle 1 


i 


mListenerList.finishBroadcast(); 


到 这 里 ，AIDL 的 基本 使 用 方法 已 经 介绍 完了 ， 但 是 有 几 点 还 需要 
再 次 说 明 一 下 。 我 们 知道 ， 客 户 端 调 用 远程 服务 的 方法 ， 被 调用 的 方 
法 运行 在 服务 端的 Binder 线 程 池 中 ， 同 时 客户 端 线 程 会 被 挂 起 ， 这 个 
时 候 如 果 服 务 端 方法 执行 比较 耗 时 ， 束 会 导致 客户 端 线程 长 时 间 地 阻 
塞 在 这 里 ， 而 如 采 这 个 客户 端 线程 是 UI 线 程 的 话 ， 怠 会 导致 客户 端 
ANR， 这 当然 不 是 我 们 想 要 看 到 的 。 因 此 ， 如 采 我 们 明确 知道 某 个 远 
程 方法 是 耗 时 的 ， 那 么 融 要 避免 在 客户 端的 UI 线 程 中 去 访问 远程 方 
法 。 由 于 客户 端的 onServiceConnected 和 onService Disconnected 方 法 都 
运行 在 UI 线程 中 ， 所 以 也 不 可 以 在 它们 里 面 直接 调用 服务 端的 耗 时 方 
法 ， 这 点 要 尤其 注意 。 另 外 ， 由 于 服务 端的 方法 本 喘 束 运行 在 服务 端 
的 Binder 线 程 池 中 ， 所 以 服务 端 方 法 本 里 就 可 以 执行 大 量 耗 时 操作 ， 
这 个 时 候 切 记 不 要 在 服务 端 方法 中 开 线程 去 进行 异步 任务 ， 除 非 你 明 
确 知 道上 自己 在 和 干什么， 否则 不 建议 这 么 做 。 下 面 我 们 稍微 改造 一 下 上 服 


务 端 的 getBookList 广 法， 我 们 假定 这 个 方法 是 耗 时 的 ， 那 么 服务 端 可 
以 这 么 实现 : 


然后 在 客户 端 中 放 一 个 按钮 ， 单 击 它 的 时 候 殉 会 调用 服务 端的 
getBookList 方 法 ， 可 以 预知 ， 连 续 单 击 儿 次 ， 客 户 闻 天 ANR 了 ， 如 图 
2-7 所 示 ， 感 兴趣 读者 可 以 自行 试 一 仆 。 


A RER! 


活动 BookManagerActivity ( 在 
应 用 程序 Chapter_2 中 ) 无 响 
Mo 


图 2-7 UI 线程 中 调用 远程 耗 时 方法 导致 的 ANR 


避免 出 现 上 述 这 种 ANR 其 实 很 商 单 ， 我 们 只 需要 把 调用 放 在 非 UI 
线程 即 可 ， 如 下 所 示 。 


public void onButton1Click(View view) { 
Toast.makeText(this, "click 
button1",Toast.LENGTH_SHORT).show(); 
new Thread(new Runnable() { 
@Override 
public void run() { 
if (mRemoteBookManager != null) { 
try { 
List<Book> newList = 
mRemoteBookManager .getBookList(); 
} catch (RemoteException e) { 


e.printStackTrace(); 


F 
}).start(); 


i 


同 理 ， 当 远程 服务 端 需要 调用 客户 端的 listener 中 的 方法 时 ， 被 调 
用 的 方法 也 运行 在 Binder 线 程 池 中 ， 只 不 过 是 客户 端的 线程 池 。 所 
以 ， 我 们 同样 不 可 以 在 服务 端 中 调用 客户 端的 耗 时 方法 。 比 如 针对 
BookManagerService 的 onNewBookArrived 方 法 ， 如 下 所 示 。 在 它 内 部 
调用 了 客户 端的 IOnNewBookArrivedListener 中 的 onNewBookArrived 方 
法 ， 如 果 客 户 端的 这 个 onNewBookArrived 方 法 比较 耗 时 的 话 ， 那 么 请 


确保 BookManagerService 中 的 onNewBookArrived 运 行 在 非 UI 线 程 中 ， 
否则 将 导致 服务 端 无 法 啊 应 。 


private void onNewBookArrived(Book book) throws 
RemoteException { 
mBookList.add(book); 
Log.d(TAG, "onNewBookArrived,notify listeners:" + 
mListenerList. 
size()); 
Tor (dme L = OF 1 < mE IStenenList .sTzef), Iam) Af 
IOnNewBookArrivedListener listener = 
mListenerList.get(i); 
Log.d(TAG, "onNewBookArrived, notify listener:" + 
listener); 


listener .onNewBookArrived(book) ; 


i 


另外 ， 由 于 客户 端的 IOnNewBookArrivedListener 中 的 
onNewBookArrived 方 法 运行 在 客户 端的 Binder 线 程 池 中 ， 所 以 不 能 在 
它 里 面 去 访问 UI 相关 的 内 容 ， 如 果 要 访问 UI， 请 使 用 Handler 切 换 到 UI 
线程 ， 这 一 点 在 前 面 的 代码 实例 中 已 经 有 所 体现 ， 这 里 束 不 再 详细 朱 
mL y o 


为 了 程序 的 健壮 性 ， 我 们 还 需要 做 一 件 事 。Binder 是 可 能 意外 死 
亡 的 ， 这 往往 是 由 于 服务 端 进程 意外 停止 了 ， 这 时 我 们 需要 重新 连接 
服务 。 有 两 种 方法 ， 第 一 种 方法 是 给 Binder 设 置 DeathRecipient 监 听 ， 
当 Binder 和 死亡 时 ， 我 们 会 收 到 binderDied 方 法 的 回调 ， 在 binderDied 方 


法 中 我 们 可 以 重 连 远程 服务 ， 具 体 方法 在 Binder 那 一 市 已 经 介绍 过 
了 ， 这 里 就 不 再 详细 描述 了 。 男 一 种 方法 是 在 onServiceDisconnected 中 
重 连 远程 服务 。 这 两 种 方法 我 们 可 以 随便 选择 一 种 来 使 用 ， 它 们 的 区 
别 在 于 : onServiceDisconnected 在 客户 端的 UI 线程 中 被 回调 ， 而 
binderDied E & F m AY Binder $% F£ WE P g Ey The UL, E 
binderDied 方 法 中 我 们 不 能 访问 UI， 这 就 是 它们 的 区 别 。 下 面 验证 一 
下 二 者 之 则 的 区 别 ， 首 先 我 们 通过 DDMS 杀 死 服 务 端 进程 ， 接 着 在 这 
两 个 方法 中 打印 出 当前 线程 的 名 称 ， 如 下 所 示 。 


D/BookManagerActivity(13652): onServiceDisconnected. 
tname:main 

D/BookManagerActivity(13652): binder died. tname:Binder 
Thread #2 


从 上 面 的 log 和 图 2-8 我 们 可 以 看 到 ，onServiceDisconnected 运 行 在 
main 线 程 中 ， 即 UI 线程 ， 而 binderDied 运 行 在 “Binder Thread#2” 这 个 线 
程 中 ， 很 显然 ， 它 是 Binder 线 程 池 中 的 一 个 线程 。 


Devices 5 = O & Threads X 
88.9322 & ID Tid Status utime stime Name 
>, > 
v 1 14220 Native 12 4 main 
Name “2 14221 VmWait 0 1 HeapWorker 
a @ htc-htc_a510e-SH1AGTR18501 Online | “2 19222 VmWait 2) Fe 
com.fd.httpd 3445 *4 14223 VmWait 0 O Signal Catcher 
com.iflytek.inputmethod 271 5 14224 Runnable 2 3 JDWP 
com.ryg.chapter_2 14220 *6 14225 VmWait 0 0 Compiler 
com.ryg.chapter_2:remote 14250 7 14226 Native 0 O Binder Thread #1 
8 14227 Native 0 0 Binder Thread #2 
Refresh Mon Feb 16 00:15:00 CST 2015 
at dalvik.system.NativeStart.run(Native Method) 


图 2-8 DDMS 中 的 线程 信息 


到 此 为 止 ， 我 们 已 经 对 AIDL 有 了 一 个 系统 性 的 认识 ， 但 是 还 差 最 
后 一 步 : 如 何在 AIDL 中 使 用 权限 验证 功能 。 默 认 情况 下 ， 我 们 的 远程 
服务 任何 人 都 可 以 连接 ， 但 这 应 该 不 是 我 们 愿意 看 到 的 ， 所 以 我 们 必 
须 给 服务 加 入 权限 验证 功能 ， 权 限 验 证 失败 则 无 法 调用 服务 中 的 方 
法 。 在 AIDL 中 进行 权限 验证 ， 这 里 介绍 两 种 党 用 的 方法 。 


第 一 种 方法 ， 我 们 可 以 在 onBind 中 进行 验证 ， 验 证 不 通过 束 直 接 
返回 null， 这 样 难 证 失败 的 客户 端 直接 无 法 绑 定 服务 ， 至 于 验证 方式 
可 以 有 多 种 ， 比 如 使 用 permission 难 证 。 使 用 这 种 验证 方式 ， 我 们 要 先 
在 AndroidMenifest 中 声明 所 需 的 权限 ， 比 如 : 


<permission 


android:name="com.ryg.chapter_2.permission.ACCESS_BOOK_SERVICE" 


android:protectionLevel="normal" /> 


关于 permission 的 定义 方式 请 读者 查看 相关 资料 ， 这 里 就 不 详细 展 
开 了 ， 毕 竟 本 和 的 主要 内 容 是 介绍 AIDL。 定 义 了 权限 以 后 ， 束 可 以 在 
BookManagerService 的 onBind 方 法 中 做 权限 验证 了 ， 如 下 所 示 。 


public IBinder onBind(Intent intent) { 
int check = 
checkCallingOrSelfPermission("com.ryg.chapter_2. 
permission.ACCESS_BOOK_SERVICE"); 
if (check == PackageManager.PERMISSION_ DENIED) { 


return null; 


return mBinder; 


} 


一 个 应 用 来 绑 定 我 们 的 服务 时 ， 会 验证 这 个 应 用 的 权限 ， 如 采 它 
没有 使 用 这 个 权限 ，onBind 方 法 束 会 直接 返回 null， 最 终结 有 果 是 这 个 应 
用 无 法 绑 定 到 我 们 的 服务 ， 这 样 惑 达到 了 权限 验证 的 效果 ， 这 种 方法 
同样 适用 于 Messenger 中 ， 读 者 可 以 目 行 扩展 。 


如 采 我 们 目 己 内 部 的 应 用 想 绑 定 到 我 们 的 服务 中 ， 只 需要 在 它 的 
AndroidMenifest 文 件 中 采用 如 下 方式 使 用 permission 即 可 。 


<uses-permission 
android:name="com.ryg.chapter_2.permission.ACCESS_BOOK_ 


SERVICE" /> 


第 二 种 方法 ， 我 们 可 以 在 服务 端的 onTransact 方 法 中 进行 权限 验 
证 ， 如 果 验 证 失败 就 直接 返回 false， 这 样 服务 端 就 不 会 终止 执行 AIDL 
中 的 方法 从 而 达到 保护 服务 端的 效果 。 至 于 具体 的 验证 方式 有 很 多 ， 
可 以 采用 permission 验 证 ， 具 体 实现 方式 和 第 一 种 方法 一 样 。 还 可 以 采 
用 Uid 和 Pid 来 做 验证 ， 通 过 getCallingUid 和 getCallingPid 可 以 拿 到 客户 
器 所 属 应 用 的 Uid 和 Pid， 通 过 这 两 个 参数 我 们 可 以 做 一 些 验 证 工作 ， 
比如 验证 包 名 。 在 下 面 的 代码 中 ， 既 验证 了 permission， 又 验证 了 包 
名 。 一 个 应 用 如 果 想 远程 调用 服务 中 的 方法 ， 首 先 要 使 用 我 们 的 目 定 
义 权 限 “com.ryg.chapter_2.permission.ACCESS_BOOK_SERVICE”， 其 
次 包 名 必须 以 “com.ryg” 开 始 ， 否 则 调用 服务 端的 方法 会 失败 。 


public boolean onTransact(int code,Parcel data,Parcel 


reply, int flags) 


上 面 介 绍 了 两 种 AIDL 中 常用 的 权限 验证 方法 ， 但 是 肯定 还 有 其 他 
方法 可 以 做 权限 验证 ， 比 如 为 Service 指 定 android:permission 属 性 等 ， 
这 里 就 不 一 一 进行 介绍 了 。 到 这 里 为 止 ， 本 广 的 内 容 就 全 部 结束 了 ， 
读者 应 该 对 AIDL 的 使 用 过 程 有 很 深入 的 理解 了 ， 接 下 来 会 介绍 另 一 个 
IPC 方 式 ， 那 就 是 使 用 ContentProvider 。 


2.4.5 “使 用 ContentProvider 


ContentProvider 是 Android 中 提供 的 专门 用 于 不 同 应 用 间 进 行 数据 
共享 的 方式 ， 从 这 一 点 来 看 ， 它 天 生 束 适合 进程 间 通 信 。 和 Messenger 
一 样 ，ContentProvider 的 故 层 实现 同样 也 是 Binder， 由 此 可 见 ，Binder 
在 Android 系 统 中 是 何等 的 重要 。 虽 然 ContentProvider 的 底层 实现 是 
Binder， 但 是 它 的 使 用 过 程 要 比 AIDL 简 单 许 多 ， 这 是 因为 系统 已 经 为 
我 们 做 了 封装 ， 使 得 我 们 无 须 天 心底 层 细 和 即 可 轻松 实现 IPC。 
ContentProvider 虽然 使 用 起 来 很 简单 ， 包 括 目 己 创建 一 个 
ContentProvider 也 不 是 什么 难事 ， 尽 管 如 此 ， 它 的 细节 还 是 相当 多 ， 
比如 CRUD 操 作 、 防 止 SQL 注 入 和 权限 控制 等 。 由 于 章节 主题 限制 ， 
在 本 节 中 ， 笔 者 暂时 不 对 ContentProvider 的 使 用 细节 以 及 工作 机 制 进 
行 详细 分 析 ， 而 是 为 读者 介绍 采用 ContentProvider 进 行路 进程 通信 的 
主要 流程 ， 至 于 使 用 细 地 和 内 部 工作 机 制 会 在 后 续 章 下 进行 详细 分 
析 。 


系统 预 置 了 许多 ContentProvider， 比 如 通讯 录 人 信息、 日 程 表 信息 
等 ， 要 路 进程 访问 这 些 信息 ， 只 需要 通过 ContentResolver 的 query、 
update、insert 和 delete 方 法 即 可 。 在 本 和 中 ， 我 们 来 实现 一 个 自 定 义 的 
ContentProvider， 并 演示 如 何在 其 他 应 用 中 获取 ContentProvider 中 的 数 
据 从 而 实现 进程 间 通 信 这 一 目的 。 首 先 ， 我们 创建 一 个 
ContentProvider ， 和 名 字 就 叫 BookProvider。 创 建 一 个 和 目 定 义 的 
ContentProvider 很 简单 ， 只 需要 继承 ContentProvider 类 并 实现 六 个 抽象 
方法 即 可 : onCreate、qduery、update、insert、delete 和 getType。 这 六 个 
抽象 方法 都 很 好 理解 ，onCreate 代 表 ContentProvider 的 创建 ， 一 般 来 说 
我 们 需要 做 一 些 初 始 化 工作 ; getType 用 来 返回 一 个 Uri 请 求 所 对 应 的 


MIME 类 型 (媒体 类 型 ) ， 比 如 图 片 、 视 频 等 ， 这 个 媒体 类 型 还 是 有 
点 复杂 的 ， 如 果 我 们 的 应 用 不 关注 这 个 选项 ， 可 以 直接 在 这 个 方法 中 
返回 null 或 者 “*/*”， 剩 下 的 四 个 方法 对 应 于 CRUD 操 作 ， 即 实现 对 数据 
表 的 增删 改 查 功能 。 根 据 Binder 的 工作 原理 ， 我 们 知道 这 六 个 方法 均 
运行 在 ContentProvider 的 进程 中 ， 除 了 onCreate 由 系统 回调 并 运行 在 主 
线程 里 ， 其 他 五 个 方法 均 由 外 界 回调 并 运行 在 Binder 线 程 池 中 ， 这 一 
扩 在 接 下 来 的 例子 中 可 以 再 次 证 明 。 


ContentProvider 主 要 以 表格 的 形式 来 组 织 数据 ， 并 且 可 以 包含 多 
个 表 ， 对 于 每 个 表格 来 说 ， 它 们 都 具有 行 和 列 的 层次 性 ， 行 往往 对 应 
一 条 记录 ， 而 列 对 应 一 条 记录 中 的 一 个 字段 ， 这 点 和 数据 库 很 类 似 。 
除了 表格 的 形式 ，ContentProvider 还 支持 文件 数据 ， 比 如 图 片 、 视 频 
等 。 文 件数 据 和 表格 数据 的 结构 不 同 ， 因 此 处 理 这 类 数据 时 可 以 在 
ContentProvider 中 返回 文件 的 句柄 给 外 界 从 而 让 文件 来 访问 
ContentProvider 中 的 文件 信息 。Android 系 统 所 提供 的 MediaStore 功 能 
就 古文 件 类 型 的 ContentProvider， 详 细 实 现 可 以 参考 MediaStore。 男 
外 ， 虽 然 ContentProvider 的 故 层 数据 看 起 来 很 像 一 个 SQLite 数 据 库 ， 但 
是 ContentProvider 对 底层 的 数据 存储 方式 没有 任何 要 求 ， 我 们 既 可 以 
使 用 SQLite 数 据 库 ， 也 可 以 使 用 普通 的 文件 ， 甚 至 可 以 采用 内 存 中 的 
一 个 对 象 来 进行 数据 的 存储 ， 这 一 点 在 后 续 的 章节 中 会 再 次 介绍 ， 所 
以 这 里 不 再 深入 了 。 


下 面 看 一 个 最 简单 的 示例 ， 它 演示 了 ContentProvider 的 工作 工 
程 。 首 先 创 建 一 个 BookProvider 类 ， 它 继承 自 ContentProvider 并 实现 了 
ContentProvider 的 六 个 必须 需要 实现 的 抽象 方法 。 在 下 面 的 代码 中 ， 
我 们 什么 都 没 干 ， 尽 管 如 此 ， 这 个 BookProvider 也 是 可 以 工作 的 ， 只 
是 它 无 法 癌 外 界 提 供 有 效 的 数据 而 已 。 


return null; 
} 
@Override 

public int delete(Uri uri,String selection, String[] 
selectionArgs) { 

Log.d(TAG, "delete"); 

return 0; 
J 
@Override 


public int update(Uri uri,ContentValues values, String 


selection, 
String[] selectionArgs) { 
Log.d(TAG, "update"); 
return 0; 
} 
} 


接着 我 们 需要 注册 这 个 BookProvider ， 如 下 所 示 。 其 中 
android:authorities 是 Content-Provider 的 唯一 标识 ， 通 过 这 个 属性 外 部 应 
用 就 可 以 访问 我 们 的 BookProvider， 因 此 ，android:authorities 必 须 是 唯 
一 的 ， 这 里 建议 读者 在 命名 的 时 候 加 上 包 名 前 绥 。 为 了 演示 进程 间 通 
信 ， 我 们 让 BookProvider 运 行 在 独立 的 进程 中 并 给 它 添加 了 权限 ， 这 
© 外界 应 用 如 果 想 访问 BookProvider , I MM FR 
明 “com.ryg.PROVIDER” 这 个 权限 。ContentProvider 的 权限 还 可 以 细 分 
为 读 权 限 和 写 权 限 ， 分 别 对 应 android:readPermission 和 
android:writePermission 属 性 ， 如 宁 分 别 声明 了 读 权 限 和 写 权 限 ， 那 么 
外 界 应 用 也 必须 依次 声明 相应 的 权限 才 可 以 进行 读 / 写 操作 ， 人 否则 外 界 


EI AS SS 


<provider 
android:name=".provider.BookProvider" 
android:authorities="com.ryg.chapter_2.book.provider" 
android:permission="com.ryg.PROVIDER" 
android:process=":provider" > 


</provider> 


注册 了 ContentProvider 以 后 ， 我 们 就 可 以 在 外 部 应 用 中 访问 它 
了 。 为 了 方便 演示 ， 这 里 仍然 选择 在 同一 个 应 用 的 其 他 进程 中 去 访问 
这 个 BookProvider， 至 于 在 单独 的 应 用 中 去 访问 这 个 BookProvider， 和 
同一 个 应 用 中 访问 的 效果 是 一 样 的 ， 读 者 可 以 自行 试 一 下 ERB 
明 对 应 权限 ) 。 


//ProviderActivity.java 


public class ProviderActivity extends Activity { 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_provider); 
Uri uri = 


Uri.parse("content://com.ryg.chapter_2.book.provider"); 
getContentResolver().query(uri, null, null, null, null); 


getContentResolver().query(uri,null, null, nul1, null); 


getContentResolver().query(uri,null, null, nul1, null); 
} 
J 


在 上 面 的 代码 中 ， 我 们 通过 ContentResolver 对 象 的 query 方 法 去 碍 


询 BookProvider 中 的 数 据 i 其 
中 “content://com.ryg.chapter 2.book.provider” 唯一 标识 了 


BookProvider ， 而 这 个 标识 正 是 我 们 前 面 为 BookProvider 的 
android:authorities 属 性 所 指定 的 值 。 我 们 运行 后 看 一 下 log。 从 下 面 log 
可 以 看 出 ，BookProvider 中 的 query 方 法 被 调用 了 三 次 ， 并 且 这 三 次 调 
用 不 在 同一 个 线程 中 。 可 以 看 出 ， 它 们 运行 在 一 个 Binder 线 程 中 ， 前 
面 提 到 update、insert 和 delete 方 法 同样 也 运行 在 Binder 线 程 中 。 另 外 ， 
onCreate 运 行 在 main 线 程 中 ， 也 惑 症 UI 线程 ， 所 以 我 们 不 能 在 onCreate 
中 做 耗 时 操作 。 


D/BookProvider(2091): onCreate, current thread:main 
D/BookProvider(2091): query,current thread:Binder Thread +2 
D/BookProvider(2091): query,current thread:Binder Thread +1 
D/BookProvider(2091): query,current thread:Binder Thread +2 
D/MyApplication(2091): application start,process 
name:com.ryg.chapter_ 


2:provider 


到 这 里 ， 整 个 ContentProvider 的 流程 我 们 已 经 跑 通 了 ， 虽 然 
ContentProvider 中 没有 返回 任何 数据 。 接 下 来 ， 在 上 面 的 基础 上 ， 我 
们 继续 完善 BookProvider， 从 而 使 其 能 够 对 外 部 应 用 提供 数据 。 继 续 
本 章 提 到 的 那个 例子 ， 现 在 我 们 要 提供 一 个 BookProvider， 外 部 应 用 


可 以 通过 BookProvider 来 访问 图 书信 息 ， 为 了 更 好 地 演示 
ContentProvider 的 使 用 ， 用 户 还 可 以 通过 BookProvider 访 问 到 用 户 信 
居 。 为 了 完成 上 述 功 能 ， 我 们 需要 一 个 数据 库 来 管理 图 书 和 用 户 信 
妃 ， 这 个 数据 库 不 难 实现 ， 代 人 码 如 下 : 


// DbOpenHelper. java 
public class DbOpenHelper extends SQLiteOpenHelper { 
private static final String DB_NAME = 
"book_provider.db"; 
public static final String BOOK_TABLE_NAME = "book"; 
public static final String USER_TALBE_NAME = "user"; 
private static final int DB_VERSION = 1; 
// 图 书 和 用 户 信 息 表 
private String CREATE_BOOK_TABLE = "CREATE TABLE IF 


NOT EXISTS " 
+ BOOK_TABLE_NAME + "(_id INTEGER PRIMARY 
KEY," + "name TEXT)"; 
private String CREATE_USER_TABLE = "CREATE TABLE IF 
NOT EXISTS " 
+ USER_TALBE_NAME + "(_id INTEGER PRIMARY 
KEY," + "name TEXT," + 
"sex INT)"; 
public DbOpenHelper (Context context) { 
super (context, DB_NAME, null, DB_VERSION) ; 
} 
@Override 


public void onCreate(SQLiteDatabase db) { 


db.execSQL(CREATE_BOOK_TABLE); 
db.execSQL(CREATE_USER_TABLE); 
t 
@Override 
public void onUpgrade(SQLiteDatabase db,int 
oldVersion,int newVersion) { 


// TODO ignored 


} 


上 有 述 代 码 是 一 个 最 简单 的 数据 库 的 实现 ， 我 们 借助 
SQLiteOpenHelper 来 管理 数据 库 的 创建 、 升 级 和 降级 。 下 面 我 们 就 要 
通过 BookProvider 回 外 界 提供 上 述 数据 库 中 的 信息 了 。 我 们 知道 ， 
ContentProvider 通 过 Uri 来 区 分 外 界 要 访问 的 的 数据 集合 ， 在 本 例 中 文 
持 外 界 对 BookProvider 中 的 book 表 和 user 表 进行 访问 ， 为 了 知道 外 界 要 
访问 的 是 哪个 表 ， 我 们 需要 为 它们 定义 单独 的 Uri 和 Uri Code, #44 
Uri 和 对 应 的 Uri_Code 相 关联 ， 我 们 可 以 使 用 UriMatcher 的 addURTI 方 法 
将 Uri 和 Uri_Code 天 联 到 一 起 。 这 样 ， 当 外 界 请 求 访问 BookProvider 
时 ， 我 们 就 可 以 根据 请 求 的 Uri 来 得 到 Uri_Code， 有 了 Uri_Code 我 们 就 
可 以 知道 外 界 想 要 访问 哪个 表 ， 然 后 就 可 以 进行 相应 的 数据 操作 了 ， 
具体 代码 如 下 所 示 。 


public class BookProvider extends ContentProvider { 
private static final String TAG = "BookProvider"; 
public static final String AUTHORITY = 
"com.ryg.chapter_2.book. 


provider"; 


从 上 面 代码 可 以 看 出 ， 我 们 分 别 为 book 表 和 user 表 指定 了 Uri， 分 


别 

为 “content://com.ryg.chapter_2.book.provider/book” 和 “content://com.ryg. 
chapter_2.book. provider/user”， 这 两 个 Uri 所 天 联 的 Uri_Code 分 别 为 0 和 
1° 这 个 天 联 过 程 是 通过 下 面 的 语句 来 完成 的 : 


sUriMatcher .addURI (AUTHORITY, "book", BOOK_URI_CODE); 
sUriMatcher .addURI (AUTHORITY, "user", USER_URI_CODE); 


将 Uri 和 Uri_Code 管 理 以 后 ， 我 们 就 可 以 通过 如 下 方式 来 获取 外 界 
所 要 访问 的 数据 源 ， 根 据 Uri 先 取出 Uri_Code， 根 据 Uri_Code 再 得 到 数 
据 表 的 名 称 ， 知 道 了 外 界 要 访问 的 表 ， 接 下 来 束 可 以 啊 应 外 界 的 增删 
改 查 请 求 了 。 


private String getTableName(Uri uri) { 

String tableName = null; 

switch (sUriMatcher.match(uri)) { 

case BOOK_URI_CODE: 
tableName = DbOpenHelper .BOOK_TABLE_NAME; 
break; 

case USER_URI_CODE: 
tableName = DbOpenHelper .USER_TALBE_NAME; 
break; 
default :break; 

i 

return tableName; 


} 


RE, Fe |e a) LAX query ` update ` insert ` delete 1% Y” > ill 
下 是 query 方 法 的 实现 ， 上 
ESE BRP SES 递 的 查询 参数 就 可 以 进行 数据 库 的 查询 操作 了 ， 
过 程 比 较 人 简单 。 


@Override 
public Cursor query(Uri uri,String[] projection, String 
selection, 
String[] selectionArgs,String sortOrder) { 
Log.d(TAG, "query, current thread:" 十 
Thread.currentThread().getName()); 
String table = getTableName(uri); 
if (table == null) { 
throw new IllegalArgumentException("Unsupported 
URI: " + uri); 
} 
return 
mDb.query(table, projection, selection, selectionArgs, null, null, so 


rtOrder, null); 
} 


另外 三 个 方法 的 实现 思想 和 query 是 类 似 的 ， 只 有 一 点 不 同 ， 那 就 
是 update、insert 和 delete 方 法 会 引起 数据 源 的 改变 ， 这 个 时 候 我 们 需 
通 过 ContentResolver 的 notifyChange 方法 来 通知 外 界 当 前 
ContentProvider 中 的 数据 已 经 发 生 改 变 。 要 观察 一 个 ContentProvider 中 
的 数据 改变 情况 ， 可 以 通过 ContentResolver 的 registerContentObserver 
方法 来 注册 观察 者 ， 通 过 unregisterContentObserver 方 法 来 解除 观察 
者 。 对 于 这 三 个 方法 ， 这 里 不 再 详细 解释 了 ，BookProvider 的 完整 代 
码 如 下 : 


public class BookProvider extends ContentProvider { 


private static final String TAG = "BookProvider"; 


需要 注意 的 是 ，query、update、insert、delete 四 大 方法 是 存在 多 
线程 并 发 访问 的 ， 因 此 方法 内 部 要 做 好 线程 同步 。 在 本 例 中 ， 由 于 采 
用 的 是 SQLite 并 且 只 有 一 个 SQLiteDatabase 的 连接 ， 所 以 可 以 正确 应 对 


多 线程 的 情况 。 有 具体 原因 是 SQLiteDatabase 内 部 对 数据 库 的 操作 是 有 
同步 处 理 的 ， 但 是 如 果 通 过 多 个 SQLiteDatabase 对 象 来 操作 数据 库 就 
无 法 保证 线程 同步 ， 因 为 SQLiteDatabase 对 象 之 间 无 法 进行 线程 同 
步 。 如 采 ContentProvider 的 底层 数据 集 是 一 块 内 存 的话 ， 比 如 是 List， 
在 这 种 情况 下 同 List 的 吉 历 、 插 入 、 删 除 操作 就 需 要 进行 线程 同步 ， 
否则 融会 引起 并 发 错误 ， 这 点 是 尤其 需要 注意 的 。 到 这 里 
BookProvider 已 经 实现 完成 了 ， 接 着 我 们 在 外 部 访问 一 下 它 ， 看 看 是 
否 能 够 正常 工作 。 


public class ProviderActivity extends Activity { 
private static final String TAG = "ProviderActivity"; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 


super.onCreate(savedInstanceState); 


Uri bookUri = 
Uri.parse("content://com.ryg.chapter_2.book.provider/ 
book"); 
ContentValues values = new ContentValues(); 
values.put("_id",6); 
values.put("name" "程序 设计 的 艺术 ") ， 
getContentResolver().insert(bookUri, values); 
Cursor bookCursor = 
getContentResolver().query(bookUri,new String[ ] 
{"_id", "name"},null,null,null); 
while (bookCursor.moveToNext()) { 


Book book = new Book(); 


默认 情况 下 ，BookProvider 的 数据 库 中 有 三 本 书 和 两 个 用 户 ， 在 
上 面 的 代码 中 ， 我 们 首先 添加 一 本 书 :“ 程 序 设计 的 艺术 ”。 接 着 查询 
所 有 的 图 书 ， 这 个 时 候 应 该 查询 出 四 本 书 ， 因 为 我 们 刚刚 添加 了 一 
本 。 然 后 查询 所 有 的 用 户 ， 这 个 时 候 应 该 查询 出 两 个 用 户 。 是 不 是 这 
样 呢 ?我 们 运行 一 下 程序 ， 看 一 下 log > 


D/BookProvider( 1127): insert 
D/BookProvider( 1127): query, current thread:Binder Thread 
#1 
D/ProviderActivity( 1114): query book: 
[bookId:3, bookName: Android] 
D/ProviderActivity( 1114): query book: 
[bookId:4, bookName: Ios] 
D/ProviderActivity( 1114): query book: 
[bookId:5, bookName:Htm15 ] 
D/ProviderActivity( 1114): query book: [bookId:6, bookName: FE 
序 设计 的 艺术 ] 
D/MyApplication( 1127): application start,process 
name:com.ryg.chapter_ 
2:provider 
D/BookProvider( 1127): query,current thread:Binder Thread 
#3 
D/ProviderActivity( 1114): query user:User: 
{userId:1, userName: jake, 
isMale:true},with child: {null} 
D/ProviderActivity( 1114): query user:User: 
{userId:2,userName: jasmine, 


isMale:false},with child: {null} 


从 上 述 log 可 以 看 到 ， 我 们 的 确 查 询 到 了 4 本 书 和 2 个 用 户 ， 这 说 明 
BookProvider 已 经 能 够 正确 地 处 理 外 部 的 请 求 了 ， 读 者 可 以 目 行 验证 
— F update # delete $è FE, EM TERBUET- AN, AT 
ProviderActivity 和 BookProvider 运 行 在 两 个 不 同 的 进程 中 ， 因 此 ， 这 也 


构成 了 进程 间 的 通信 。ContentProvider 除 了 支持 对 数据 源 的 增删 改 查 
这 四 个 操作 ， 还 文 持 自 定 义 调 用 ， 这 个 过 程 是 通过 ContentResolve 的 
Call 方 法 和 ContentProvider 的 Call 方法 来 完成 的 。 关 于 使 用 
ContentProvider 来 进行 IPC 残 介绍 到 这 里 ，ContentProvider 本 号 还 有 一 
些 细节 这 里 并 没有 介绍 ， 读 者 可 以 自行 了 解 ， 本 章 侧重 的 是 各 种 进程 
间 通 信 的 方法 以 及 它们 的 区 别 ， 因 此 针对 某 种 特定 的 方法 可 能 不 会 介 
绍 得 面面俱到 。 男 外 ，ContentProvider 在 后 续 章节 还 会 有 进一步 的 讲 
解 ， 主 要 包括 细节 问题 和 工作 原理 ， 读 者 可 以 阅读 后 面 的 相应 章 广 。 


2.4.6 ”使 用 Socket 


在 本 证 中， 我 们 通过 Socket 来 实现 进程 间 的 通信 。 Socket 也 称 
为 “ 套 接 字 ”， 有 十 网 络 通 信 中 的 概念 ， 它 分 为 流 式 套 接 字 和 用 户 数据 报 
套 接 字 两 种 ， 分 别 对 应 于 网 络 的 传输 控制 层 中 的 TCP 和 UDP 协 议 。 
TCP 协 议 是 面向 连接 的 协议 ， 提 供 稳定 的 双 辣 通信 功能 ，TCP 连 接 的 
建立 需要 经 过 “三 次 握手 ”才能 完成 ， 为 了 提供 稳定 的 数据 传输 功能 ， 
其 本 吴 提 供 了 超时 重 传 机 制 ， 因 此 具有 很 高 的 稳定 性 ;而 UDP 是 无 连 
接 的 ， 提 供 不 稳 定 的 单 回 通信 功能 ， 当 然 UDP 也 可 以 实现 双 加 通信 功 
能 。 在 性 能 上 ，UDP 具 有 更 好 的 效率 ， 其 缺点 是 不 保证 数据 一 定 能 够 
正确 传输 ， 尤 其 是 在 网 络 拥塞 的 情况 下 。 关 于 TCP 和 UDP 的 介绍 束 这 
么 多 ， 更 评 细 的 资料 请 查看 相关 网 络 资料 。 接 下 来 我 们 演示 一 个 跨 进 
程 的 聊天 程序 ， 两 个 进程 可 以 通过 Socket 来 实现 信息 的 传输 ，Socket 本 
身 可 以 支持 传输 任意 字 节 流 ， 这 里 为 了 位 单 起 见 ， 仪 仅 传输 文本 信 
轧 ， 很 显然 ， 这 是 一 种 IPC 方 式 。 


使 用 Socket 来 进行 通信 ， 有 两 点 需要 注意 ， 首 允 需 要 声明 权限 : 


<uses-permission android:name="android.permission. INTERNET" 


<uses-permission 


android:name="android.permission.ACCESS_NETWORK_STATE" /> 


其 次 要 注意 不 能 在 主线 程 中 访问 网 络 ， 因 为 这 会 导致 我 们 的 程序 
无 法 在 Android 4.0 及 其 以 上 的 设备 中 运行 ， 会 抛 出 如 下 弄 第 : 
android.os.NetworkOnMainThreadException ° 而 且 进 行 网 络 操作 很 可 能 
是 耗 时 的 ， 如 果 放 在 主线 程 中 会 影响 程序 的 啊 应 效率 ， 从 这 方面 来 
说 ， 也 不 应 该 在 主线 程 中 访问 网 络 。 下 面 就 开始 设计 我 们 的 聊天 室 程 
序 了 ， 比 较 简 单 ， 首 先 在 远程 Service 建 立 一 个 TCP 服 务 ， 然 后 在 主 界 
面 中 连 授 TCP 服务， 连接 上 了 以 后 ， 束 可 以 给 服务 端 发 消息 。 对 于 我 
们 发 送 的 每 一 条 文本 消息 ， 服 务 端 都 会 随机 地 回应 我 们 一 句 话 。 为 了 
更 好 地 展示 Socket 的 工作 机 制 ， 在 服务 端 我 们 做 了 人 处理， 使 其 能 够 和 
多 个 客户 端 同时 建立 连接 并 啊 应 。 


先 看 一 下 服务 端的 设计 ， 当 Service 启 动 时 ， 会 在 线程 中 建立 TCP 
服务 ， 这 里 监听 的 古 8688 端 口 ， 然 后 束 可 以 等 等 客户 闻 的 连接 请 求 。 
当 有 客户 端 连 接 时 ， 吏 会 生成 一 个 新 的 Socket ， 通 过 每 次 新 创建 的 
Socket 束 可 以 分 别 和 不 同 的 客户 站 通信 了 。 服 务 端 每 收 到 一 次 客户 端 
的 消 轧 束 会 随机 回复 一 句 话 给 客户 端 。 当 客户 端 断 开 连 授时 ， 服 务 端 
这 边 也 会 相应 的 关闭 对 应 Socket 并 结束 通话 线程 ， 这 点 是 如 何 做 到 的 
WE? 方法 有 很 多 ， 这 里 是 通过 判断 服务 端 和 输 入 流 的 返回 值 来 确定 的 ， 
当 客 户 端 晰 开 连 接 后 ， 服 务 端 这 边 的 输入 流 会 返回 null， 这 个 时 候 我 
们 就 知道 客户 端 退出 了 。 服 务 端 的 代码 如 下 所 示 。 


public class TCPServerService extends Service { 


private boolean mIsServiceDestoryed = false; 


接着 看 一 下 客户 端 ， 客 户 端 Activity 启 动 时 ， 会 在 onCreate 中 开启 
一 个 线程 去 连接 服务 端 Socket， 至 于 为 什么 用 线程 在 前 面 已 经 做 了 介 
绍 。 为 了 确定 能 够 连接 成 功 ， 这 里 采用 了 超时 重 过 的 策略 ， 每 次 连接 
失败 后 都 会 重新 建立 党 试 建立 连接 。 当 然 为 了 降低 重 试 机 制 的 开销 ， 
我 们 加 入 了 体 眼 机 制 ， 即 每 次 重 试 的 时 间 间 隔 为 1000 毫 秒 。 


服务 端 连接 成 功 以 后 ， 就 可 以 和 服务 端 进行 通信 了 。 下 面 的 代码 
在 线程 中 通过 while 循 环 不 断 地 去 读 取 服 务 端 发 送 过 来 的 请 四 ， 同 时 当 
Activity 退 出 时 ， 束 退出 循环 并 终止 线程 。 


同时 ， 当 Activity 退 出 时 ， 还 要 关闭 当 前 的 Socket， 如 下 所 示 。 


接着 征 发 送 消 轧 的 过 程 ， 这 个 束 很 简单 了 ， 这 里 不 再 详细 说 明 。 
客户 并 的 完整 代码 如 下 : 


Ed Socke AA A EEN, BR AMTICPE 
接 字 ， 还 可 以 采用 UDP 套 接 字 。 另 外 ， 上 面 的 例子 仅仅 是 一 个 示例 ， 
实际 上 通过 Socket 不 仅仅 能 实现 进程 间 的 通信 ， 还 可 以 实现 设备 间 的 
通信 ， 当 然 前 提 是 这 些 设备 之 间 的 耳 地 址 互相 可 见 ， 这 其 中 又 涉及 许 
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果 ， 如 图 2-9 所 示 。 


TCPClientActivity 


server (22:02:52): 欢 迎 来 到 聊天 室 ! 

self (22:03:08): {RF IA 

server (22:03:08): (59718 , 0808 

self (22:03:25): 很 高 兴 见 到 你 ! 

server (22:03:25): 给 你 讲 个 笑话 吧 : 据说 爱 笑 的 人 运气 不 
会 太 差 ， 不 知道 真 假 ， 


发 送 


图 2-9 ”Socket 通信 示例 


2.5 “Binder 连 接 池 


上 面 我 们 介绍 了 不 同 的 IPC 方 式 ， 我 们 知道 ， 不 同 的 IPC 方 式 有 不 
同 的 特点 和 适用 场景 ， 当 然 这 个 问题 会 在 2.6 节 进行 介绍 ， 在 本 节 中 要 
再 次 介绍 一 下 ADIL ， 原 因 是 AIDL 是 一 种 最 常用 的 进程 间 通 信 方 式 ， 


日 常 开发 中 涉及 进程 则 通信 时 的 首选 ， 所 以 我 们 需要 额外 强调 一 下 


Ot fin 


如 何 使 用 AIDL 在 上 面 的 一 和 中 已 经 进行 了 介绍 ， 这 里 在 回顾 一 下 
大 致 流程 : 首先 创建 一 个 Service 和 一 个 AIDL 接 口 ， 接 着 创建 一 个 类 继 
承 目 AIDL 接 口中 的 Stub 类 并 实现 Stub 中 的 抽象 方法 ， 在 Service 的 
onBind 方 法 中 返回 这 个 类 的 对 象 ， 然 后 客户 端 承 可 以 绑 定 服务 端 
Service， 建 立 连接 后 就 可 以 访问 远程 服务 端的 方法 了 。 


上 上述 过 程 就 是 典型 的 AIDL 的 使 用 流程 。 这 本 来 也 没什么 问题 ,但 
是 现在 考虑 一 种 情况 : 公司 的 项 目 越 来 越 庞大 了 ， 现 在 有 10 个 不 同 的 
业务 模块 都 需要 使 用 AIDL 来 进行 进程 间 通 信 ， 那 我 们 该 怎么 处 理 呢 ? 
也 许 你 会 说 : “ 吏 按 照 AIDL 的 实现 方式 一 个 个 来 吧 ”， 这 是 可 以 的 ， 如 
果 用 这 种 方法 ， 首 先 我 们 需要 创建 10 个 Service， 这 好 像 有 点 多 啊 ! 如 
果 有 100 个 地 方 需要 用 到 AIDL 呢 ， 先 创建 100 个 Service? 到 这 里 ， 读 者 
应 该 明日 问题 所 在 了 。 随 着 AIDL 数 量 的 增加 ， 我 们 不 能 无 限制 地 增加 
Service，Service 是 四 大 组 件 之 一 ， 本 喘 丈 是 一 种 系统 资源 。 而 且 太 多 
的 Service 会 使 得 我 们 的 应 用 看 起 来 很 重量 级 ， 因 为 正在 运行 的 Service 
可 以 在 应 用 详情 页 看 到 ， 当 我 们 的 应 用 详情 显示 有 10 个 服务 正在 运行 
时 ， 这 看 起 来 并 不 是 什么 好 事 。 针 对 上 述 问 题 ， 我 们 需要 减少 Service 
的 数量 ， 将 所 有 的 AIDL 放 在 同一 个 Service 中 去 管理 。 


在 这 种 模式 下 ， 整 个 工作 机 制 是 这 样 的 : 每 个 业务 模块 创建 目 己 
的 AIDL 接 口 并 实现 此 接口 ， 这 个 时 候 不 同业 务 模块 之 间 是 不 能 有 帮 合 
的 ， 所 有 实现 细 市 我 们 要 单独 开 来 ， 然 后 向 服务 端 提 供 目 己 的 唯一 标 
识 和 其 对 应 的 Binder 对 象 ， 对 于 服务 端 来 说 ， 只 需要 一 个 Service 束 可 
以 了 ， 服 务 端 提供 一 个 queryBinder 接 口 ， 这 个 接口 能 够 根据 业务 模块 
的 特征 来 返回 相应 的 Binder 对 象 给 它们 ， 不 同 的 业务 模块 拿 天 所 需 的 


Binder 对 象 后 


忠 可 以 进行 远程 方法 调用 了 。 由 此 可 见 ，Binder 连 接 池 的 


主要 作用 束 是 将 每 个 业务 模块 的 Binder 请 求 统 一 转发 到 远程 Service 中 


去 执行 ， 从 而 避免 了 重复 创建 Service 的 过 程 ， 它 的 工作 原理 如 图 2-10 
所 示 。 
AIDL P~d A Binder 
AIDL A E A Binde | 
A. AIDL a T — d A Binder 
AIDL a A Binder 
客户 端 Binder 连 接 池 


图 2-10 “Binder 连 接 池 的 


通过 上 面 的 理论 介绍 ， 也 许 还 有 点 不 好 理解 ， 
池 的 代码 实现 做 一 下 说 明 。 首 先 ， 为 了 说 明 问 题 ， 
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下 面 对 Binder 连 接 
我 们 提供 了 两 个 


AIDL 接 口 (ISecurityCenter 和 ICompute) 来 模拟 上 面 提 到 的 多 个 


模块 都 要 使 用 AIDL 的 情况 ， 其 中 ISecurityCenter 授 口 提供 加 解密 


能 ， 声 明 如 下 : 


interface ISecurityCenter { 


String encrypt(String content); 


String decrypt(String password); 


} 


而 ICompute 接 口 提供 计算 加 法 的 功能 ， 


interface ICompute { 


int add(int a,int b); 


Ty 


声明 如 下 : 


虽然 说 上 面 两 个 接口 的 功能 都 比较 简单 ， 但 是 用 于 分 析 Binder 连 
接 池 的 工作 原理 已 经 足够 了 ， 读 者 可 以 写 出 更 复杂 的 例 和 于。 接着 看 一 
下 上 面 两 个 AIDL 接 口 的 实现 ， 也 比较 简单 ， 代 码 如 下 : 


return a + b; 


i 


现在 业务 模块 的 AIDL 接 口 定义 和 实现 都 已 经 完成 了 ， 注 意 这 里 并 
没有 为 每 个 模块 的 AIDL 单 独创 建 Service， 接 下 来 就 是 服务 端 和 Binder 
连接 池 的 工作 了 。 


首先 ， 为 Binder 连 接 池 创建 AIDL 接 口 IBinderPoolaidl， 代 码 如 下 
所 示 。 


interface IBinderPool { 
JE 
* @param binderCode,the unique token of specific 
Binder<br/> 
* @return specific Binder who's token is binderCode. 
yA 
IBinder queryBinder (int binderCode); 


} 


接着 ， 为 Binder 连 接 池 创建 远程 Service 并 实现 IBinderPool， 下 面 
是 queryBinder 的 具体 实现 ， 可 以 看 到 请 求 转 发 的 实现 方法 ， 当 Binder 
连接 池 连 接 上 远程 服务 时 ， 会 根据 不 同 模块 的 标识 即 binderCode 返 回 
不 同 的 Binder 对 象 ， 通 过 这 个 Binder 对 象 所 执行 的 操作 全 部 发 生 在 远程 
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@Override 


public IBinder queryBinder(int binderCode) throws 
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下 面 还 剩 下 Binder 连 接 池 的 具体 实现 ， 在 它 的 内 部 首先 它 要 去 绑 
定 远 程 服务 ， 绑 定 成 功 后 ， 客 户 端 就 可 以 通过 它 的 queryBinder 方 法 去 
获取 各 目 对 应 的 Binder， 拿 到 所 需 的 Binder 以 后 ， 不 同业 务 模块 就 可 以 


进行 各 自 的 操作 了 ，Binder 连 接 池 的 代码 如 下 所 示 。 


Binder ERA AMAIA, CREAR LAN, 
针对 上 面 的 例子 ， 我 们 只 需要 创建 一 个 Service 即 可 完成 多 个 AIDL 接 口 
的 工作 ， 下 面 我 们 来 验证 一 下 效果 。 新 创建 一 个 Activity， 在 线程 中 执 
行 如 下 操作 : 


e.printStackTrace(); 
} 
Log.d(TAG, "visit ICompute"); 
IBinder computeBinder = binderPool 

.queryBinder (BinderPool.BINDER_COMPUTE); 

mCompute = ComputeImpl.asInterface(computeBinder ) ; 
try { 

System.out.printin("3+5=" + mCompute.add(3,5)); 
} catch (RemoteException e) { 


e.printStackTrace(); 


在 上 述 代 码 中 ， 我 们 先后 调用 了 ISecurityCenter 和 ICompute 这 两 个 
AIDL 接 口中 的 方法 ， 看 一 下 log， 很 显然 ， 工 作 正常 。 


D/BinderPoolActivity(20270): visit ISecurityCenter 


I/System.out(20270): content:helloworld-%# 


I/System.out(20270): encrypt:6;221)1,2:s HR 


I/System.out(20270): decrypt:helloworld-%# 
D/BinderPoolActivity(20270): visit ICompute 
I/System.out(20270): 3+5=8 


这 里 需要 额外 说 明 一 下 ， 为 什么 要 在 线程 中 去 执行 呢 ? 这 是 因为 
在 Binder 连 接 池 的 实现 中 ， 我 们 通过 CountDownLatch 将 bindService 这 
一 异步 操作 转换 成 了 同步 操作 ， 这 束 意 味 着 它 有 可 能 是 耗 时 的 ， 然 后 
就 是 Binder 方 法 的 调用 过 程 也 可 能 是 耗 时 的 ， 因 此 不 建议 放 在 主线 程 
去 执行 。 注 意 到 BinderPool 是 一 个 单 例 实现 ， 因 此 在 同一 个 进程 中 只 


会 初始 化 一 次 ， 所 以 如 果 我 们 提前 初始 化 BinderPool， 那 么 可 以 优化 
程序 的 体验 ， 比 如 我 们 可 以 放 在 Application 中 提前 对 BinderPool 进 行 初 

化， 虽然 这 不 能 你 证 当 我 们 调用 BinderPool 时 它 一 定 是 初始 化 好 
的 ， 但 是 在 大 多 数 情况 下 ， 这 种 初始 化 工作 〈 绑 定 远程 服务 ) 的 时 间 
开销 (如 果 BinderPool 没 有 提前 初始 化 完成 的 话 ) 是 可 以 接受 的 。 另 
外 ，BinderPool 中 有 上 断 线 重 连 的 机 制 ， 当 远程 服务 意外 终止 时 ， 
BinderPool 会 重新 建立 连接 ， 这 个 时 候 如 有 果 业 务 模块 中 的 Binder 调 用 出 
现 了 异常 ， 也 需要 手动 去 重新 获取 最 新 的 Binder 对 象 ， 这 个 是 需要 注 
意 的 。 


有 了 BinderPool 可 以 大 大 方便 日 常 的 开发 工作 ， 比 如 如 有 果 有 一 个 
新 的 业务 模块 需要 添加 新 的 AIDL， 那 么 在 它 实 现 了 自己 的 AIDL 接 口 
后 ， 只 需要 修改 BinderPoolImpl 中 的 queryBinder 方 法 ， 给 目 己 添加 一 个 
新 的 binderCode 并 返回 对 应 的 Binder 对 象 即 可 ， 不 需要 做 其 他 修改 ， 也 
不 需要 创建 新 的 Service。 由 此 可 见 ，BinderPool 能 够 极 大 地 提高 AIDL 
的 开发 效率 ， 并 且 可 以 避免 大 量 的 Service 创 建 ， 因 此 ， 建 议 在 AIDL 开 
发 工作 中 引入 BinderPool 机 制 。 


2.6 ”选用 合适 的 IPC 方 式 


在 上 面 的 一 市 中 ， 我 们 介绍 了 各 种 各 样 的 IPC 方 式 ， 那 么 到 压 它 
们 有 什么 不 同 呢 ? 我们 到 故 该 使 用 哪 一 种 呢 ? 本 市 整 为 读者 解答 这 些 
问题 ， 具 体内 容 如 表 2-2 所 示 。 通 过 表 2-2， 可 以 明确 地 看 出 不 同 IPC 方 
式 的 优 缺 点 和 适用 场景 ， 那 么 在 实际 的 开发 中 ， 只 要 我 们 选择 合适 的 
IPC 方 式 束 可 以 轻松 完成 多 进程 的 开发 场景 。 


表 2-2 IPPC 方式 的 优 缺 氮 和 适用 场景 


名 W 


Ro 


适用 场景 


Bundle 


文件 共享 


Messenger 


ContentProvider 


Socket 


简单 易 用 


简单 易 用 


功能 强大 ， 支 持 一 对 多 并 发 通 
信 ， 支 持 实时 通信 


功能 一 般 ， 支 持 一 对 多 串 行 通 
信 ， 支 持 实时 通信 


在 数据 源 访问 方面 功能 强大 , 支 
持 一 对 多 并 发 数据 共享 ， 可 通过 
Call 方法 扩展 其 他 操作 

功能 强大 , 可 以 通过 网 络 传输 字 
节 流 ， 支 持 一 对 多 并 发 实时 通信 


只 能 传输 Bundle 支持 的 数据 
类 型 

不 适合 高 并 发 场景 ， 并 且 无 
法 做 到 进程 间 的 即时 通信 

使 用 稍 复杂 ， 需 要 处 理 好 线 
程 同步 

不 能 很 好 处 理 高 并 发 情形 , 不 
支持 RPC, 数据 通过 Message 进 
行 传输 ， 因 此 只 能 传输 Bundle 
支持 的 数据 类 型 


可 以 理解 为 受 约束 的 AIDL， 
主要 提供 数据 源 的 CRUD 操作 


实现 细节 稍微 有 点 烦琐 ， 不 
支持 直接 的 RPC 


四 大 组 件 间 的 进程 间 通 信 


无 并 发 访问 情形 ,交换 简单 的 
数据 实时 性 不 高 的 场景 


-对 多 通信 且 有 RPC 需求 


低 并 发 的 一 对 多 即时 通信 ,无 
RPC 需求 ， 或 者 无 须要 返回 结 
果 的 RPC 需求 


-对 多 的 进程 间 的 数据 共享 


FE “View 的 事件 体系 


本 草 将 介绍 Android 中 十 分 重要 的 一 个 概念 : View， 虽 然 说 View 
不 属于 四 大 组 件 ,但 是 它 的 作用 堪 比 四 大 组 件 ， 其 至 比 Receiver 和 
Provider 的 重要 性 都 要 大 。 在 Android 开 发 中 ，Activity 承 担 这 可 视 化 的 
功能 ， 同 时 Android 系 统 提 供 了 很 多 基础 控件 ， 常 见 的 有 Button、 
TextView、CheckBox 等 。 很 多 时 候 仅 仅 使 用 系统 提供 的 控件 是 不 能 满 
足 需 求 的 ， 因 此 我 们 束 需 要 能 够 根据 需求 进行 新 控件 的 定义 ， 而 控件 
的 目 定 义 束 需 要 对 Android 的 View 体 系 有 深入 的 理解 ， 只 有 这 样 才能 写 
出 完美 的 目 定 义 控 件 。 同 时 Android 手 机 属于 移动 设备 ， 移 动 设 备 的 一 
个 特点 束 是 用 户 可 以 直接 通过 屏幕 来 进行 一 系列 操作 ， 一 个 典型 的 场 
景 束 是 屏幕 的 请 动 ， 用 户 可 以 通过 请 动 来 切换 到 不 同 的 界面 。 很 多 情 
况 下 我 们 的 应 用 都 需要 文 持 请 动 操 作 ， 当 处 于 不 同 层 级 的 View 都 可 以 
啊 应 用 户 的 滑动 操作 时 ， 束 会 带 来 一 个 问题 ， 那 束 是 滑动 冲突 。 如 何 
解决 消 动 冲突 呢 ? 这 对 于 初学 者 来 说 的 确 是 个 头 疫 的 问题 ， 其 实 解决 
滑动 冲突 本 不 难 ， 它 需要 读者 对 View 的 事件 分 发 机 制 有 一 定 的 了 解 ， 
在 这 个 基础 上 ， 我 们 就 可 以 利于 这 个 特性 从 而 得 出 滑动 冲突 的 解决 方 
法 。 上 述 这 些 内 容 就 是 本 章 所 要 介绍 的 内 容 ， 同 时 ，View 的 内 部 工作 
原理 和 上 自 定义 View 相 关 的 知识 会 在 第 4 章 进 行 介 绍 。 


31 ” View 基础 知识 


本 市 主要 介绍 View 的 一 些 基础 知识 ， 从 而 为 更 好 地 介绍 后 续 的 内 
容 做 铺垫 。 主 要 介绍 的 内 容 有 : View 的 位 置 参 数 、MotionEvent 和 


TouchSlop 对 象 、VelocityTracker、GestureDetector 和 Scroller 对 象 ， 通 过 
对 这 些 基 础 知识 的 介绍 ， 可 以 方便 读者 理解 更 复杂 的 内 容 。 类 似 的 基 
础 概念 还 有 不 少 ， 但 是 本 世 所 介绍 的 都 是 一 些 比较 常用 的 ， 其 他 不 常 
用 的 基础 概念 读者 可 以 自行 了 解 。 


3.1.1 什么 是 View 


在 介绍 View 的 基础 知识 之 前 ， 我 们 首先 要 知道 到 底 什 么 是 View。 
View 是 Android 中 所 有 控件 的 基 类 ， 不 管 是 简单 的 Button 和 TextView 还 
是 复杂 的 RelativeLayout 和 ListView， 它 们 的 共同 基 类 都 是 View。 所 以 
说 ，View 是 一 种 界面 层 的 控件 的 一 种 抽象 ， 它 代表 了 一 个 控件 。 除 了 
View， 还 有 ViewGroup， 从 名 字 来 看 ， 它 可 以 被 翻译 为 控件 组 ， 言 外 
之 意 是 ViewGroup 内 部 包含 了 许多 个 控件 ， 即 一 组 View。 在 Android 的 
设计 中 ，ViewGroup 也 继承 了 View， 这 就 意味 着 View 本 身 束 可 以 是 单 
个 控件 也 可 以 是 由 多 个 控件 组 成 的 一 组 控件 ， 通 过 这 种 关系 束 形 成 了 
View 树 的 结构 ， 这 和 Web 前 端 中 的 DOM 树 的 概念 是 相似 的 。 根 据 这 个 
概念 ， 我 们 知道 ，Button 显 然 是 个 View， 而 LinearLayout 不 但 是 一 个 
View 而 且 还 是 一 个 ViewGroup， 而 ViewGroup 内 部 是 可 以 有 子 View 的 ， 
这 个 子 View 同 样 还 可 以 是 ViewGroup， 依 此 类 推 。 


明日 View 的 这 种 层级 关系 有 助 于 理解 View 的 工作 机 制 。 如 图 3-1 
所 示 ， 可 以 看 到 目 定 义 的 TestButton 是 一 个 View， 它 继承 了 TextView， 
而 TextView 则 直接 继承 了 View， 因 此 不 管 怎么 说 ，TestButton 都 是 一 个 
View， 同 理 我 们 也 可 以 构造 出 一 个 继承 和 目 ViewGroup 的 控件 。 


Type hierarchy of 'com.ryg.chapter_3.ui.TestButton': 


s C) Object jā a tanc 


a 四 View - and o d.vie 
a © TextView - android.widget 
"9 TestButton - com.ryg.chapter_3.ui 


图 3-1 ”TestButton 的 层次 结构 


3.1.2 ”View 的 位 置 参 数 


View 的 位 置 主要 由 它 的 四 个 顶点 来 决定 ， 分 别 对 应 于 View 的 四 个 
属性 : top、left、right、bottom， 其 中 top 是 左上 角 纵 坐标 ，left 是 左上 
角 横 坐标 ，right 是 右 下 角 横 坐标 ，bottom 是 右 下 角 纵 坐标 。 需 要 注音 
的 是 ， 这 些 坐 标 都 是 相对 于 View 的 父 容 吉 来 说 的 ， 因 此 它 是 一 种 相对 
坐标 ，View 的 坐标 和 父 容器 的 天 系 如 图 3-2 所 示 。 在 Android 中 ，x 轴 和 
y 轴 的 正方 同 分别 为 右 和 下 ， 这 点 不 难 理解 ， 不 仅 仅 是 Android， 大 部 
分 显示 系统 都 是 按照 这 个 标准 来 定义 坐标 系 的 。 


ight _> 


ViewGroup 


图 3-2 ”View 的 位 置 坐 标 和 父 容 器 的 关系 


根据 图 3-2， 我 们 很 容易 得 出 View 的 宽 高 和 坐标 的 关系 : 


width = right - left 
height = bottom - top 


那么 如 何 得 到 View 的 这 四 个 参数 呢 ? 也 很 向 单 ， 在 View 的 源码 中 
它们 对 应 于 mLeft、mRight、mTIop 和 mBottom 这 四 个 成 员 变 量 ， 获 取 
方式 如 下 所 示 。 


e Left=getLeft(); 
e Right=getRight(); 


e Top=getTop; 
。 Bottom=getBottom() ° 


从 Android3.0 开 始 ，View 增 加 了 额外 的 几 个 参数 : x yy > 
translationX Al translationY, 其 中 x 和 y 是 View 左 上 角 的 坐标 ， 而 
translationX 和 和 translationY 是 View 左 上 和 角 相 对 于 父 容 器 的 偏 移 量 。 这 几 
个 参数 也 是 相对 于 父 容器 的 坐标 ， 并 且 translationX 和 translationY 的 默 
认 值 是 9， 和 View 的 四 个 基本 的 位 置 参数 一 样 ，View 也 为 它们 提供 了 
get/set 方 法 ， 这 几 个 参数 的 换算 关系 如 下 所 示 。 


x=left+translationX 


y=top+translationY 


需要 注意 的 是 ，View 在 平移 的 过 程 中 ，top 和 left 表 示 的 是 原始 左 
上 和 角 的 位 置信 息 ， 其 值 并 不 会 发 生 改 变 ， 此 时 发 生 改 变 的 是 x、y、 


translationX 和 translationY 这 四 个 参数 。 


3.1.3 ”MotionEvent 和 TouchSlop 


1. MotionEvent 


在 手指 接触 屏幕 后 所 产生 的 一 系列 事件 中 ， 典 型 的 事件 类 型 有 如 
FILE: 


e ACTION_ DOWN ”手指 刚 接触 屏幕 ; 
e ACTION MOVE—— 手指 在 屏幕 上 移动 ; 
。ACTION_UP 一 一 手机 从 屏幕 上 松 开 的 一 瞬间 。 


IER TROL T, RETRATA A A ADA AE, 
考虑 如 下 几 种 情况 : 


。 点 击 屏 幕后 离开 松 开 ， 事 件 序列 为 DOWN -> UP; 
。 点 击 屏 幕 滑 动 一 会 再 松 开 ， 事 件 序 列 为 DOWN -> MOVE -> ... > 
MOVE -> UP + 


上 述 三 种 情况 是 典型 的 事件 序列 ， 同 时 通过 MotionEvent 对 象 我 们 
可 以 得 到 点 击 事件 发 生 的 x 和 y 坐 标 。 为 此 ， 系 统 提 供 了 两 组 方法 : 
getX/getY 和 getrRawX/getRawY。 它 们 的 区 别 其 实 很 简单 ，getX/getY 返 
回 的 是 相对 于 当前 View 左 上 角 的 x 和 y 坐 标 ， 而 getRawX/getRawY 返 回 
的 是 相对 于 手机 屏幕 左上 角 的 x 和 y 坐 标 。 


2. TouchSlop 


TouchSlop 是 系统 所 能 识别 出 的 被 认为 是 滑动 的 最 小 距离 ， 换 句 话 
说 ， 当 手指 在 屏幕 上 请 动 时 ， 如 果 两 次 滑动 之 间 的 距离 小 于 这 个 常 
量 ， 那 么 系统 殉 不 认为 你 是 在 进行 滑动 操作 。 原 因 很 简单 : 滑动 的 距 
离 太 短 ， 系 统 不 认为 它 是 消 动 。 这 是 一 个 常量 ， 和 设备 有 关 ， 在 不 同 
设备 上 这 个 值 可 能 是 不 同 的 ， 通 过 如 下 方式 即 可 获取 这 个 常量 : 
ViewConfiguration. get(getContext()).getScaledTouchSlop() ° 这 个 常量 有 
什么 意义 呢 ? 当 我 们 在 处 理 清 动 时 ， 可 以 利用 这 个 常量 来 做 一 些 过 
滤 ， 比 如 当 两 次 消 动 事件 的 滑动 距离 小 于 这 个 值 ， 我 们 就 可 以 认为 未 
达到 请 动 距离 的 临界 值 ， 因 此 融 可 以 认为 它们 不 是 滑动 ， 这 样 做 可 以 
有 更 好 的 用 户 体验 。 其 实 如 有 果 细 心 的 话 ， 可 以 在 源码 中 找到 这 个 常量 
的 定义 ， 在 frameworks/base/core/res/res/values/config.xml 文 件 中 ， 如 下 
所 示 。 这 个 “config_viewConfigurationTouchSlop” 对 应 的 就 是 这 个 常量 
的 定义 。 


<!--Base "touch slop" value used by ViewConfiguration as a 
movement threshold 
where scrolling should begin. --> 


<dimen name="config_viewConfigurationTouchSlop">8dp</dimen> 


3.1.4 Velocity Tracker à 
GestureDetectorAScroller 


1. Velocity Tracker 


HEER, HTERFRBERINIEFNTIER, GKF 
TRAINER: CRE RAR AA, E55, TE ViewfJonTouchEvent77 
法 中 追 踩 当 前 单 击 事件 的 速度 : 


VelocityTracker velocityTracker = VelocityTracker.obtain(); 


velocityTracker.addMovement (event); 


接着 ， 当 我 们 先知 道 当 前 的 滑动 速度 时 ， 这 个 时 候 可 以 采用 如 下 
方式 来 获得 当前 的 速度 


velocityTracker.computeCurrentVelocity(1000); 
int xVelocity = (int) velocityTracker.getXVelocity(); 


int yVelocity = (int) velocityTracker .getYVelocity(); 


在 这 一 步 中 有 两 点 需要 注意 ， 第 一 点 ， 获 取 速 度 之 前 必须 先 计算 
速度 El getXVelocity 和 getYVelocity 这 en 个 方法 的 前 面 必 须要 调用 
computeCurrentVelocity 方 法 ;第 二 点 ， 这 里 的 速度 是 指 一 段 时 间 内 手 


指 所 滑 过 的 像素 数 ， 比 如 将 时 间 间 隔 设 为 1000ms 时 ， 在 1s 内 ， 手 指 在 
水 平方 同 从 左 辣 右 滑 过 100 像 素 ， 那 么 水 平 速度 束 是 100。 注 意 速度 可 
以 为 负数 ， 当 手指 从 右 往 左 滑动 时 ， 水 平方 向 速度 即 为 负 值 ， 这 个 需 
要 理解 一 下 。 速 度 的 计算 可 以 用 如 下 公式 来 表示 : 


速度 = (终点 位 置 -起 点 位 置 ) /时 间 段 


根据 上 面 的 公式 再 加 上 Android 系 统 的 坐标 系 ， 可 以 知道 ， 手 指 逆 
春 坐 标 系 的 正方 向 滑动 ， 所 产生 的 速度 驶 为 负 值 。 另 外 ， 
computeCurrentVelocity 这 个 方法 的 参数 表示 的 是 一 个 时 间 单 元 或 者 说 
时 间 间 阿 ， 它 的 单位 是 毫秒 (m) ,计算 速度 时 得 到 的 速度 就 是 在 这 
个 时 间 间 隔 内 手指 在 水 平 或 竖 直 方向 上 所 滑动 的 像素 数 。 针 对 上 面 的 
例子 ， 如 果 我 们 通过 velocityTracker.computeCurrentVelocity(100) 来 获取 
速度 ， 那 么 得 到 的 速度 就 是 手指 在 100ms 内 所 请 过 的 像素 数 ， 因 此 水 
平 速 度 就 成 了 10 像 素 /每 100ms (这 里 假设 渭 动 过 程 是 匀速 的 ， 即 水 
平 速度 为 10， 这 点 需要 好 好 理解 一 下 。 


最 后 ， 当 不 需要 使 用 它 的 时 候 ， 需 要 调用 clear 方 法 来 重 置 并 回收 
内 存 : 


velocityTracker.clear(); 


velocityTracker.recycle(); 


上 面 就 是 如 何 使 用 VelocityTracker 对 象 的 全 过 程 ， 看 起 来 并 不 复 


Zu o 


2. GestureDetector 


手势 检测 ， 用 于 辅助 检测 用 户 的 单 击 、 滑 动 、 长 按 、 双 击 等 行 
为 。 要 使 用 GestureDetector 也 不 复杂 ， 参 考 如 下 过 程 。 


首先 ， 需 要 创建 一 个 GestureDetector 对 象 并 实现 OnGestureListener 
接口 ， 根 据 需 要 我 们 还 可 以 实现 OnDoubleTapListener 从 而 能 够 监听 双 
ITA: 


GestureDetector mGestureDetector = new 
GestureDetector(this); 
// 解 决 长 按 屏幕 后 无 法 拖 动 的 现象 


mGestureDetector.setIsLongpressEnabled(false); 


BZ, RE A E View onTouchEvent HE, EEE WET View 的 
onTouchEvent 方 法 中 添加 如 下 实现 : 


boolean consume = mGestureDetector .onTouchEvent(event); 


return consume; 


做 完了 上 面 两 步 ， 我 们 就 可 以 有 选择 地 实现 OnGestureListener 和 
OnDoubleTapListener 中 的 方法 了 ， 这 两 个 接口 中 的 方法 介绍 如 表 3-1 所 
aR o 


3-1 OnGestureListener 和 OnDoubleTapListener 中 的 方法 介绍 


方法 名 Ho E 所 属 接 口 
onDown E 指 轻 轻 触摸 屏幕 的 一 有 瞬间， 由 1 个 ACTION_DOWN 触发 OnGestureListener 


onShowPress BEER; TN O ee i OnGestureListener 
* 注意 和 onDownO) 的 区 别 ， 它 强调 的 是 没有 松 开 或 者 拖 动 的 状态 


End 手指 ( 轻 轻 触摸 屏幕 后 ) 松 开 ， 伴 随 着 1 个 MotionEvent ACTION_UP 6 
onSingleTapU' E ue. RSS OnGestureListener 
ren 而 触发 ， 这 是 单 击 行为 

手指 按 下 屏幕 并 拖 动 ,由 1 个 ACTION DOWN, 多 个 ACTION_ MOVE 


onScroll a Sera OnGestureListener 
触发 ， 这 是 拖 动 行为 


onLongPress 用 户 长 久 地 按 着 屏幕 不 放 ， 即 长 按 OnGestureListener 


用 户 按 下 触摸 屏 、 快 速 滑动 后 松 开 ， 由 1 个 ACTION_ DOWN、 多 个 
nFling z EME OnGestureL istener 
a. ACTION MOVE fil 1 个 ACTION UP 触发 ， 这 是 快速 滑动 行为 a T S 


双击 ， 由 2 次 连续 的 单 击 组 成 ， 它 不 可 能 和 onSingleTapConfirmed 4 
onDoubleTap OnDoubleTapListener 
7 


严格 的 单 击 行为 
*# 注 意 它 和 onSingleTapUp 的 区 别 ,， 如 果 触 发 了 onSingleTapConfirmed， 
onSingleTapConfirmed ange . as a8 ee, ____. | OnDoubleTapListener 
那么 后 面 不 可 能 再 紧 跟 着 另 一 个 单 击 行为 ， 即 这 只 可 能 是 单 击 ， 而 不 可 
能 是 双击 中 的 一 次 单 击 
表示 发 生 了 双击 行为 ， 在 双击 的 期 间 ，ACTION_ DOWN 、 


onDoubleTapEvent OnDoubleTapListener 
pS ACTION_MOVE 和 ACTION UP 都 会 触发 此 回调 和 


表 3-1 里 面 的 方法 很 多 ， 但 是 并 不 是 所 有 的 方法 都 会 被 时 党 用 到 ， 

在 日 常 开发 中 ， 比 较 常 用 的 有 : onSingleTapUp (i) > onFling ( 快 
速 滑 动 ) > onScroll 〈 拖 动 ) > onLongPress (长 按 ) 和 onDoubleTap 

ME) 。 另 外 这 里 要 说 明 的 是 ， 实 际 开 发 中 ， 可 以 不 使 用 
GestureDetector， 完 全 可 以 目 己 在 View 的 onTouchEvent 方 法 中 实现 所 需 
的 监听 ， 这 个 就 看 个 人 的 喜好 了 。 这 里 有 一 个 建议 供 读 者 参考 : 如果 
只 是 监听 请 动 相关 的 ， 建 议 目 己 在 onTouchEvent 中 实现 ， 如 果 要 监听 
双击 这 种 行为 的 话 ， 那 么 惑 使 用 GestureDetector 。 


3. Scroller 


弹性 滑动 对 象 ， 用 于 实现 View 的 弹性 滑动 。 我 们 知道 ， 当 使 用 
View 的 scrollTo/scrollBy 方 法 来 进行 请 动 时 ， 其 过 程 是 瞬间 完成 的 ， 这 
个 没有 过 渡 效 果 的 滑动 用 户 体验 不 好 。 这 个 时 候 束 可 以 使 用 Scroller 来 
实现 有 过 流 效 果 的 谓 动 ， 其 过 程 不 是 瞬间 完成 的 ， 而 是 在 一 定 的 时 间 
间隔 内 完成 的 。Scroller 本 喘 无 法 让 View 弹 性 滑动 ， 它 需要 和 View 的 


computeScroll 方 法 配合 使 用 才能 共同 完成 这 个 功能 。 那 么 如 何 使 用 
Scroller WE? 它 的 典型 代码 是 固定 的 ， 如 下 所 示 。 人 至 于 它 为 什么 能 实现 
弹性 请 动 ， 这 个 在 3.2 节 中 会 进行 详细 介绍 。 


Scroller scroller = new Scroller (mContext); 
// 缓慢 滚动 到 指定 位 置 
private void smoothScrollTo(int destX,int destY) { 


int scrollX = getScrollX(); 

int delta = destX -scrollX; 

// 1000msflläfldestx, rel 
mScroller.startScroll(scrol1X,0,delta,0,1000); 


invalidate(); 
J 
@Override 
public void computeScroll() { 
if (mScroller.computeScrolloffset()) { 


scrollTo(mScroller.getCurrX(),mScroller.getCurrY()); 


postInvalidate(); 


3.2 ”View 的 滑动 


3.1 市 介绍 了 View 的 一 些 基 础 知识 和 概念 ， 本 节 开 始 介绍 很 重要 的 
一 个 内 容 : View 的 滑动 。 在 Android 设 备 上 ， 滑 动 几 乎 是 应 用 的 标 配 ， 


不 管 是 下 拉 刷 新 还 是 SlidingMenu， 它 们 的 基础 都 是 请 动 。 从 另外 一 方 
面 来 说 ，Android 手 机 由 于 屏幕 比较 小 ， 为 了 给 用 户 呈 现 更 多 的 内 容 ， 
瓯 需要 使 用 滑动 来 隐藏 和 显示 一 些 内 容 。 基 于 上 述 两 点 ， 可 以 知道 ， 
滑动 在 Android 开 发 中 具有 很 重要 的 作用 ， 不 管 一 些 请 动 效果 多 人 么 绚 
丽 ， 归 根 结 原 ， 它 们 都 是 由 不 同 的 滑动 外 加 一 些 特效 所 组 成 的 。 
此 ， 掌 握 滑动 的 方法 是 实现 绚丽 的 目 定 义 控 件 的 基础 。 通 过 三 种 方式 
可 以 实现 View 的 滑动 : 第 一 种 是 通过 View 本 号 提供 的 scrollTo/scrollBy 
方法 来 实现 滑动 ; 第 二 种 是 通过 动画 给 View 施 加 平移 效果 来 实现 请 
动 ; 第 三 种 是 通过 改变 View 的 LayoutParams 使 得 View 重 新 布局 从 而 实 
现 消 动 。 从 目前 来 看 ， 和 常见 的 消 动 方式 就 这 么 三 种 ， 下 面 一 一 进行 分 
Pr ° 


3.2.1 ”使 用 scrollTo/scrollBy 


为 了 实现 View 的 滑动 ，View 提 供 了 专门 的 方法 来 实现 这 个 功能 ， 
那 就 是 scrollTo 和 scrollBy， 我 们 先 来 看 看 这 两 个 方法 的 实现 ， 如 下 所 
A o 


/** 

* Set the scrolled position of your view. This will cause 
a call to 

* {@link #onScrollChanged(int,int,int,int)} and the view 
will be 

* invalidated. 

* @param x the x position to scroll to 


* @param y the y position to scroll to 


从 上 面 的 源码 可 以 看 出 ，scrollBy 实 际 上 也 是 调用 了 scrollTo 方 
法 ， 它 实现 了 基于 当前 位 置 的 相对 滑动 ， 而 scrollTo 则 实现 了 基于 所 传 
递 参 数 的 绝对 滑动 ， 这 个 不 难 理解 。 利 用 scrollTo 和 scrollBy 来 实现 
View 的 请 动 ， 这 不 是 一 件 困 难 的 事 ， 但 是 我 们 要 明日 请 动 过 程 中 View 
内 部 的 两 个 属性 mScrollX 和 mScrollY 的 改变 规则 ， 这 两 个 属性 可 以 通 
过 getScrollX 和 getScrollY 方 法 分 别 得 到 。 这 里 先 简 要 概况 一 下 : IH 
动 过 程 中 ，mScrollX 的 值 总 是 等 于 View 左 边 综 和 View 内 容 左 边缘 在 水 
平方 加 的 距离 ， 而 mScrolY 的 值 总 是 等 于 View 上 边缘 和 View 内 容 上 边 
绿 在 竖 直 方 问 的 距离 。View 边 缘 是 指 View 的 位 置 ， 由 四 个 顶点 组 成 ， 
而 View 内 容 边 绿 是 指 View 中 的 内 容 的 边缘 ，scrollTo 和 scrollBy 只 能 改 
变 View 内 容 的 位 置 而 不 能 改变 View 在 布局 中 的 位 置 。mScrollX 和 
mScrollY 的 单位 为 像素 ， 并 且 当 View 左 边缘 在 View 内 容 左 边缘 的 右边 
时 ，mScrollX 为 正 值 ， 反 之 为 负 值 ， 当 View 上 边缘 在 View 内 容 上 边缘 
的 下 边 时 ，mScrollY 为 正 值 ， 反 之 为 负 值 。 换 名 话说， 如 果 从 左 同 厂 
清 动 ， 那 么 mScrollX 为 负 值 ， 反 之 为 正 值 ， 如 果 从 上 往 下 滑动 ， 那 么 
mScrollY 为 负 值 ， 反 之 为 正 值 。 


为 了 更 好 地 理解 这 个 问题 ， 下 面 举 个 例子 ， 如 图 3-3 所 示 。 在 图 中 
假设 水 平和 竖 直 方向 的 滑动 距离 都 为 100 像 素 ， 针 对 图 中 各 种 请 动情 
况 ， 都 给 出 了 对 应 的 mScrollX 和 mScrollY 的 值 。 根 据 上 面 的 分 析 ， 可 
以 知道 ， 使 用 scrollTo 和 scrollBy 来 实现 View 的 请 动 ， 只 能 将 View 的 内 
容 进 行 移动 ， 并 不 能 将 View 本 喘 进 行 移动 ， 也 束 是 说 ， 不 管 怎么 滑 
动 ， 也 不 可 能 将 当前 View 请 动 到 附近 View 所 在 的 区 域 ， 这 个 需要 仔细 
体会 一 下 。 


原始 状态 
mscrollX=0 mScrollX = 100 mScrollX =-100 
mscrollY =0 


mScrollX =-100 


mScrollY = 100 mscrollY = 100 mScrollY =-100 


图 3-3 mscrolX 和 mgScrollY 的 变换 规律 示意 


3.2.2 ”使 用 动画 


上 一 节 介 绍 了 采用 scrollTo/scrollBy 来 实现 View 的 滑动 ， 本 节 介 绍 
另外 一 种 请 动 方式 ， 即 使 用 动画 ， 通 过 动画 我 们 能 够 让 一 个 View 进 行 
平移 ， 而 平移 就 是 一 种 消 动 。 使 用 动画 来 移动 View， 主 要 是 操作 View 
的 translationX 和 translationY 属 性 ， 既 可 以 采用 传统 的 View 动 画 ， 也 可 
以 采用 属性 动画 ， 如 果 采 用 属性 动画 的 话 ， 为 了 能 够 兼容 3.0 以 下 的 版 
本 ， 需要 采用 开源 动画 库 nineoldandroids 

(http://nineoldandroids.com/) ° 


采用 View 动 画 的 代码 ， 如 下 所 示 。 此 动画 可 以 在 100ms 内 将 一 个 
View 从 原始 位 置 癌 右 下 角 移 动 100 个 像素 。 


<?xml version="1.0" encoding="utf-8"?> 
<set 
xmins:android="http://schemas.android.com/apk/res/android" 

android: fillAfter="true" 
android: zAdjustment="normal" > 
<translate 

android: duration="100" 

android: fromxDelta="0" 


android: FfromYyDelta="0" 


android: interpolator="@android:anim/linear_interpolator" 
android: toxXDelta="100" 
android: toYDelta="100" /> 


</set> 


如 果 采 用 属性 动画 的 话 ， 就 更 简单 了 ， 以 下 代码 可 以 将 一 个 View 
在 100ms 内 从 原始 位 置 向 右 平移 100 像 素 。 


ObjectAnimator.ofFloat(targetView, "translationX",0,100).setDura 
tion 


(100).start(); 


上 面 简单 介绍 了 通过 动画 来 移动 View 的 方法 ， 关 于 动画 会 在 第 5 
章 中 进行 详细 说 明 。 使 用 动画 来 做 View 的 滑动 需要 注意 一 点 ，View 动 
画 是 对 View 的 影像 做 操作 ， 它 并 不 能 真正 改变 View 的 位 置 参数 ， 包 括 
冤 / 高 ， 并 且 如 末 布 望 动画 后 的 状态 得 以 保留 还 必须 将 flAfter 属 性 设 
置 为 tue， 否 则 动画 完成 后 其 动画 结果 会 消失 。 比 如 我 们 要 把 View 问 


右 移动 100 像 素 ， 如 果 filAfter 为 false， 那 么 在 动画 完成 的 一 刹那 ， 
View 会 瞬间 恢复 到 动画 前 的 状态 ; 如果 fillAfter 为 tue， 在 动画 完成 
后 ，View 会 俘 留 在 距 原 始 位 置 100 像 素 的 石 边 。 使 用 属性 动画 并 不 会 
存在 上 述 问 题 ， 但 是 在 Android 3.0 以 下 无 法 使 用 属性 动画 ， 这 个 时 候 
我 们 可 以 使 用 动画 兼容 库 nineoldandroids 来 实现 属性 动画 ， 尽 管 如 此 ， 
在 Android 3.0 以 下 的 手机 上 通过 nineoldandroids 来 实现 的 属性 动画 本 质 
上 仍然 是 View 动 画 。 


上 面 提 到 View 动 画 并 不 能 真正 改变 View 的 位 置 ， 这 会 市 来 一 个 很 
严重 的 问题 。 试 想 一 下 ， 比 如 我 们 通过 View 动 画 将 一 个 Button 回 右 移 
动 100px， 并 且 这 个 View 设 置 的 有 单 击 事件 ， 然 后 你 会 慰 奇 地 发 现 ， 
单 击 新 位 置 元 法 触发 onClick 事 件 ， 而 单 击 原始 位 置 仍然 可 以 触发 
onClick 事 件 ， 尽 管 Button 已 经 不 在 原始 位 置 了 。 这 个 问题 带 来 的 影响 
征 致命 的 ， 但 是 它 却 又 是 可 以 理解 的 ， 因 为 不 管 Button 怎 么 做 变换 ， 
但 是 它 的 位 置信 息 《四 个 顶点 和 宽 / 高 ) 并 不 会 随 着 动画 而 改变 ， 因 此 
在 系统 眼 里 ， 这 个 Button 并 没有 发 生 任 何 改 变 ， 它 的 真 映 仍然 在 原始 
位 置 。 在 这 种 情况 下 ， 单 击 新 位 置 当 然 不 会 触发 onClick 事 件 了 ， 因 为 
Button 的 真 遇 并 没有 发 生 改变 ， 在 新 位 置 上 只 十 View 的 影像 而 已 。 基 
于 这 一 点 ， 我 们 不 能 简单 地 给 一 个 View 做 平移 动画 并 且 还 硕 望 它 在 新 
位 置 继续 触发 一 些 单 击 事件 。 


从 Android 3.0 开 始 ， 使 用 属性 动画 可 以 解决 上 面 的 问题 ， 但 是 大 
多 数 应 用 都 需要 兼容 到 Android 2.2， 在 Android 2.2 上 无 法 使 用 属性 动 
画 ， 因 此 这 里 还 是 会 有 问题 。 那 么 这 种 问题 难道 束 无 法 解决 了 吗 ? 也 
不 是 的 ， 虽 然 不 能 直接 解决 这 个 问题 ,但 是 还 可 以 间接 解决 这 个 问 
题 ， 这 里 给 出 一 个 简单 的 解决 方法 。 针 对 上 面 View 动 画 的 问题 ， 我 们 
可 以 在 新 位 置 预先 创建 一 个 和 目标 Button 一 模 一 样 的 Button， 它 们 不 但 


外 观 一 样 连 onClick 事 件 也 一 样 。 当 目标 Button 完 成 平移 动画 后 ， 就 把 
目标 Button 隐 藏 ， 同 时 把 预 完 创建 的 Button 显 示 出 来 ， 通 过 这 种 间接 的 
方式 我 们 解决 了 上 面 的 问题 。 这 仪 仅 是 个 参考 ， 面 对 这 种 问题 时 读者 
可 以 灵活 应 对 。 


3.2.3 ”改变 布局 参数 


本 节 将 介绍 第 三 种 实现 View 滑 动 的 方法 ， 那 就 是 改变 布局 参数 ， 
即 改 变 LayoutParams。 这 个 比较 好 理解 了 ， 比 如 我 们 想 把 一 个 Button 回 
右 平移 100px， 我 们 只 需要 将 这 个 Button 的 LayoutParams 里 的 marginLeft 
参数 的 值 增 加 100px 即 可 ， 有 是 不 是 很 简单 呢 ? 还 有 一 种 情形 ， 为 了 达到 
移动 Button 的 目的 ， 我 们 可 以 在 Button 的 左边 放置 一 个 空 的 View， 这 
个 空 View 的 默认 宽度 为 0， 当 我 们 需要 癌 右 移动 Button 时 ， 只 需要 重新 
设置 空 View 的 宽度 即 可 ， 当 空 View 的 宽度 增 大 时 (假设 Button 的 父 容 
ARACENA HA LinearLayout) ，Button 就 自动 被 挤 向 右边 ， 即 实现 了 
癌 右 平 移 的 效果 。 如 何 重新 设置 一 个 View 的 LayoutParams 呢 ? 48 fal 
单 ， 如 下 所 示 。 


MarginLayoutParams params 
(MarginLayoutParams)mButton1.getLayoutParams(); 
params .width += 100; 
params.leftMargin += 100; 
mButton1.requestLayout(); 


// 或 者 mButton1.setLayoutParams(params ) ， 


通过 改变 LayoutParams 的 方式 去 实现 View 的 滑动 同样 是 一 种 很 灵 
活 的 方法 ， 需 要 根据 不 同情 况 去 做 不 同 的 处 理 。 


3.24 各 种 请 动 方式 的 对 比 


上 面 分 别 介绍 了 三 种 不 同 的 滑动 方式 ， 写 们 都 能 实现 View 的 清 
动 ， 那 么 它们 之 间 的 差别 是 什么 呢 ? 


先 看 scrollTo/scrollBy 这 种 方式 ， 它 是 View 提 供 的 原生 方法 ， 其 作 
用 是 专门 用 于 View 的 滑动 ， 它 可 以 比较 方便 地 实现 滑动 效果 并 且 不 影 
啊 内 部 元 系 的 单 击 事件 。 但 是 它 的 缺点 也 是 很 显然 的 : 它 只 能 滑动 
View 的 内 容 ， 并 不 能 滑动 View 本 号。 


再 看 动画 ， 通 过 动画 来 实现 View 的 滑动 ， 这 要 分 情况 。 如 果 是 
Android 3.0 以 上 并 采用 属性 动画 ， 那 么 采用 这 种 方式 没有 明显 的 缺 
点 ， 如 果 是 使 用 View 动 画 或 者 在 Android 3.0 以 下 使 用 属性 动画 ， 均 不 
能 改变 View 本 身 的 属性 。 在 实际 使 用 中 ， 如 果 动 画 元 素 不 需要 响应 用 
户 的 交互 ， 那 么 使 用 动画 来 做 滑动 是 比较 合适 的 ， 否 则 就 不 太 适 合 。 
但 是 动画 有 一 个 很 明显 的 优点 ， 那 就 是 一 些 复杂 的 效果 必须 要 通过 动 
画 才能 实现 。 


最 后 再 看 一 下 改变 布局 这 种 方式 ， 它 除了 使 用 起 来 麻烦 点 以 外 ， 
也 没有 明显 的 缺点 ， 它 的 主要 适用 对 和 象 是 一 些 具有 交互 性 的 View， 
为 这 些 View 需 要 和 用 户 区 互 ， 直 接 通过 动画 去 实现 会 有 问题 ， 这 在 
3.2.2 市 中 已 经 有 所 介绍 ， 所 以 这 个 时 候 我 们 可 以 使 用 直接 改变 布局 参 
数 的 方式 去 实现 。 


针对 上 面 的 分 析 做 一 下 总 结 ， 如 下 所 示 。 


e scrollTo/scrollBy: 操作 简单， 适合 对 View 内 容 的 请 动 ; 


动画 : 操作 简单 ， 主 要 适用 于 没有 交互 的 View 和 实现 复杂 的 动画 
效果 ; 
。 改变 布局 参数 : 操作 稍微 复杂 ， 适 用 于 有 交互 的 View。 


下 面 我 们 实现 一 个 跟 手 滑动 的 效果 ， 这 是 一 个 自 定 义 View， 拖 动 
它 可 以 让 它 在 整个 屏幕 上 随意 滑动 。 这 个 View 实 现 起 来 很 简单 ， 我 们 
只 要 重 写 它 的 onTouchEvent 方 法 并 处 理 ACTION_MOVE 事 件 ， 根 据 两 
次 滑动 之 间 的 距离 就 可 以 实现 它 的 滑动 了 。 为 了 实现 全 屏 滑 动 ， 我 们 
采用 动画 的 方式 来 实现 。 原 因 很 和 测 单 ， 这 个 效果 无 法 采用 scrollTo 来 实 
现 。 另 外 ， 它 还 可 以 采用 改变 布局 的 方式 来 实现 ， 这 里 仅仅 是 为 了 演 
示 ， 所 以 就 选择 了 动画 的 方式 ， 核 心 代码 如 下 所 示 。 


public boolean onTouchEvent(MotionEvent event) { 
int x = (int) event.getRawX(); 
int y = (int) event.getRawY(); 
switch (event.getAction()) { 
case MotionEvent.ACTION_DOWN: { 
break; 
} 
case MotionEvent.ACTION_MOVE: { 
int deltaX = x -mLastX; 
int deltaY = y -mLastY; 
Log.d(TAG, "move, deltaX:" + deltaX + " deltaY:" 
+ deltaY); 
int translation = 
(int)ViewHelper.getTranslationX(this) + deltaX; 


int translationY = 


(int)ViewHelper .getTranslationY(this) + deltaY; 
ViewHelper.setTranslationX(this,translationX); 
ViewHelper.setTranslationY(this,translationY); 
break; 

j 

case MotionEvent.ACTION_UP: { 
break; 

5 

default: 
break; 

2 

mLastX = x; 

mLastY = y; 

return true; 


A 
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单 。 首 先 我 们 通 前 过 getrRawX 和 getRawY 方 法 来 获取 手指 当前 前 的 坐标 ， 
注意 不 能 使 用 getX 和 getY 方 法 ， 因 为 这 个 是 要 全 屏 滑 动 的 ， 所 以 需要 
获取 当前 点 击 事件 在 屏幕 中 的 坐标 而 不 是 相对 于 View 本 喘 的 坐标 ;其 
次 ， 我 们 要 得 到 两 次 滑动 之 间 的 位 移 ， 有 了 这 个 位 移 就 可 以 移动 当前 
的 View， 移 动 方法 采用 的 是 动画 兼容 库 nineoldandroids 中 的 ViewHelper 
类 所 提供 的 setTranslationX 和 setTranslationY 方 法 。 实 际 上 ，ViewHelper 
类 提供 了 一 系列 get/set 方 法 ， 为 View 的 setTranslationX 和 
setTranslationY 只 能 在 Android 3.0 及 其 以 上 版 本 才能 使 用 ， 但 是 
ViewHelper 所 提供 的 方 N 版 本 要 求 的 ， 与 此 类 似 的 还 有 setX、 
setScaleX、setAlpha 等 方法 ， 这 一 系列 方法 实际 上 是 为 属性 动画 服务 


的 ， 更 详细 的 内 容 会 在 第 5 草 进 行进 一 步 的 介绍 。 这 个 目 定 义 View 可 
以 在 2.x 及 其 以 上 版 本 工作 ,但 是 由 于 动画 的 性 质 ， 如 有 果 给 它 加 上 
onClick 事 件 ， 那 么 在 3.0 以 下 版 本 它 将 无 法 在 新 位 置 啊 应 用 户 的 点 击 ， 
这 个 问题 在 前 面 已 经 提 到 过 。 


3.3 ”弹性 滑动 


知道 了 View 的 滑动 ， 我 们 还 要 知道 如 何 实现 View 的 弹性 请 动 ， 比 
较 生 硬 地 请 动 过 去 ， 这 种 方式 的 用 户 体验 实在 太 差 了 ， 因 此 我 们 要 实 
现 渐 近 式 滑 动 。 那 么 如 何 实现 弹性 滑动 昵 ? 其 实 实现 方法 有 很 多 ， 但 
是 它们 都 有 一 个 共同 思想 : 将 一 次 大 的 滑动 分 成 者 干 次 小 的 滑动 并 在 
一 个 时 间 段 内 完成 ， 弹 性 请 动 的 具体 实现 方式 有 很 多 ， 比 如 通过 
Scroller 、Handler#postDelayed 以 及 Thread#sleep 等 ， 下 面 一 一 进行 介 
绍 。 


3.3.1 ”使 用 Scroller 


Scroller 的 使 用 方法 在 3.1.4 市 中 已 经 进行 了 介绍 ， 下 面 我 们 来 分 析 
一 下 它 的 源码 ， 从 而 探究 为 什么 它 能 实现 View 的 弹性 滑动 。 


Scroller scroller = new Scroller(mContext); 

// 缓慢 滚动 到 指定 位 置 

private void smoothScrollTo(int destX,int destY) { 
int scrollX = getScrollX(); 
int deltaX = destX -scrollxX; 
// 190gms 内 滑 向 destX， 效 果 就 是 慢 慢 滑 动 


上 面 是 Scroller 的 典型 的 使 用 方法 ， 这 里 先 描述 它 的 工作 原理 : Y 
我 们 构造 一 个 Scroller 对 象 并 且 调 用 它 的 startScroll 方 法 时 ，Scroller 内 部 


其 实 什 么 也 没 做 ， 它 只 是 保存 了 我 们 传递 的 几 个 参数 ， 这 几 个 参数 从 
startScroll 的 原型 上 就 可 以 看 出 来 ， 如 下 所 示 。 


mFinalY = startY + dy; 

mDeltaX = dx; 

mDeltaY = dy; 

mDurationReciprocal = 1.0f / (float) mDuration; 


} 
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点 ，dx 和 dy 表示 的 是 要 滑动 的 距离 ， 而 duration 表 示 的 是 请 动 时 间 ， 即 
整个 滑动 过 程 完成 所 需要 的 时 间 ， 注 意 这 里 的 滑动 是 指 View 内 容 的 消 
动 而 韭 View 本 和 吴 位 置 的 改变 。 可 以 看 到 ， 仪 仅 调用 startScroll 方 法 是 无 
法 让 View 滑 动 的 ， 因 为 它 内 部 并 没有 做 滑动 相关 的 事 ， 那 么 Scroller 到 
JE se An ik View HEHE IY WE? 答案 就 是 startScrol 方法 下 面 的 
invalidate 方 法 ， 虽 然 有 点 不 可 思议 ， 但 是 的 确 是 这 样 的 。invalidate 方 
法 会 导致 View 重 绘 ， 在 View 的 draw 方 法 中 又 会 去 调用 computeScroll 方 
法 ，computeScroll 方 法 在 View 中 是 一 个 空 实 现 ， 因 此 需要 我 们 自己 去 
实现 ， 上 面 的 代码 已 经 实现 了 computeScroll 方 法 。 正 是 因为 这 个 
computeScroll 方 法 ，View 才 能 实现 弹性 请 动 。 这 看 起 来 还 是 很 抽象 ， 
其 实 这 样 的 : 当 View 重 绘 后 会 在 draw 方 法 中 调用 computeScroll， 而 
computeScroll 义 会 去 同 Scroller 获 取 当 前 的 scrollX 和 scrollY; 然后 通过 
scrollTo 方 法 实现 滑动 ， 授 着 义 调 用 postInvalidate 方 法 来 进行 第 二 次 重 
绘 ， 这 一 次 重 绘 的 过 程 和 第 一 次 重 绘 一 样 ， 还 是 会 导致 computeScroll 
方法 被 调用 ;然后 继续 辐 Scroller 获 取 当 前 的 scrollX 和 scrollY， 并 通过 
scrollTo 方 法 滑动 到 新 的 位 置 ， 如 此 反复 ， 直 到 整个 滑动 过 程 结 束 。 


我 们 再 看 一 下 Scroller 的 computeScrollOffset 方 法 的 实现 ， 如 下 所 
ZN (o) 
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的 百分比 来 算出 scrollX 和 scrollY 改 变 的 百分比 并 计算 出 当前 的 值 ， 这 
个 过 程 类 似 于 动画 中 的 插值 器 的 概念 ， 这 里 我 们 先 不 去 深究 这 个 具体 
过 程 。 这 个 方法 的 返回 值 也 很 重要 ， 它 返回 true 表 示 清 动 还 未 结束 ， 
false 则 表示 请 动 已 经 结束 ， 因 此 当 这 个 方法 返回 true 时 ， 我 们 要 继续 进 
行 View 的 请 动 。 


通过 上 面 的 分 析 ， 我 们 应 该 明白 Scroller 的 工作 原理 了 ， 这 里 做 一 
下 概括 : Scroller 本 吴 并 不 能 实现 View 的 滑动 ， 它 需要 配合 View 的 
computeScroll 方 法 才能 完成 弹性 滑动 的 效果 ， 它 不 断 地 让 View 重 绘 ， 
而 每 一 次 重 绘 距 请 动 起 始 时 间 会 有 一 个 时 间 间 隔 ， 通 过 这 个 时 间 间 隔 
Scroller 殊 可 以 得 出 View 当 前 的 滑动 位 置 ， 知 道 了 请 动 位 置 焉 可 以 通过 
scrollTo 方 法 来 完成 View 的 请 动 。 束 这 样 ，View 的 每 一 次 重 绘 都 会 导致 
View 进 行 小 幅度 的 请 动 ， 而 多 次 的 小 幅度 滑动 融 组 成 了 弹性 滑动 ， 这 
瓯 是 Scroller 的 工作 机 制 。 由 此 可 见 ，Scroller 的 设计 思想 是 多 么 值得 称 
赞 ， 整 个 过 程 中 它 对 View 没 有 丝 宫 的 引用 ， 甚 至 在 它 内 部 连 计 时 器 都 
没有 。 


332 ”通过 动画 


动画 本 身 就 是 一 种 渐 近 的 过 程 ， 因 此 通过 它 来 实现 的 滑动 天 然 就 
具有 弹性 效果 ， 比 如 以 下 代码 可 以 让 一 个 View 的 内 容 在 100ms 内 向 左 
移动 100 像 素 。 


ObjectAnimator.ofFloat(targetView, "translationX",0,100).setDura 


tion 


(100) .start(); 


不 过 这 里 想 说 的 并 不 是 这 个 问题 ， 我 们 可 以 利用 动画 的 特性 来 实 
现 一 些 动画 不 能 实现 的 效果 。 还 拿 scrollTo 来 说 ， 我 们 也 想 模 仿 Scroller 
来 实现 View 的 弹性 滑动 ， 那 么 利用 动画 的 特性 ， 我 们 可 以 采用 如 下 方 
式 来 实现 


final int startX = 0; 
final int deltaX = 100; 
ValueAnimator animator = 
ValueAnimator.ofInt(0,1).setDuration(1000); 
animator.addUpdateListener(new AnimatorUpdateListener() { 
@Override 
public void onAnimationUpdate(ValueAnimator animator) { 
float fraction = 
animator.getAnimatedFraction(); 
mButtoni1.scrollTo(startX + (int) (deltax * 
fraction),0); 
} 
}); 


animator.start(); 


在 上 述 代码 中 ， 我 们 的 动画 本 质 上 没有 作用 于 任何 对 象 上 ， 它 只 
是 在 1000ms 内 完成 了 整个 动画 过 程 。 利 用 这 个 特性 ， 我 们 就 可 以 在 动 
画 的 每 一 帧 到 来 时 获取 动画 完成 的 比例 ， 然 后 再 根据 这 个 比例 计算 出 
当前 View 所 要 滑动 的 距离 。 注 意 ， 这 里 的 请 动 针对 的 是 View 的 内 容 而 
非 View 本 号 。 可 以 发 现 ， 这 个 方法 的 思想 其 实 和 Scroller 比 较 类 似 ， 都 


是 通过 改变 一 个 百分比 配合 scrollTo 方 法 来 完成 View 的 滑动 。 需 要 说 明 
一 点 ， 采 用 这 种 方法 除了 能 够 完成 弹性 滑动 以 外 ， 还 可 以 实现 其 他 动 
画 效 果 ， 我 们 完全 可 以 在 onAnimationUpdate 方 法 中 加 上 我 们 想 要 的 其 
他 操作 。 


3.3.3 ”使 用 延 时 策略 


本 节 介 绍 另 外 一 种 实现 弹性 滑动 的 方法 ， 那 束 是 延 时 策略 。 它 的 
核心 思想 是 通过 发 送 一 系列 延 时 消息 从 而 达到 一 种 潮 近 式 的 效果 ， 具 
体 来 说 可 以 使 用 Handler 或 View 的 postDelayed 方 法 ， 也 可 以 使 用 线程 的 
sleep 方 法 。 对 于 postDelayed 方 法 来 说 ， 我 们 可 以 通过 它 来 延 时 发 送 一 
个 消息 ， 然 后 在 消息 中 来 进行 View 的 滑动 ， 如 果 接 连 不 断 地 发 送 这 种 
延 时 消息 ， 那 么 就 可 以 实现 弹性 滑动 的 效果 。 对 于 sleep 方 法 来 说 ， 通 
过 在 while 循 环 中 不 断 地 滑动 View 和 sleep， 束 可 以 实现 弹性 滑动 的 效 
果 o 


下 面 采 用 Handler 来 做 个 示例 ， 其 他 方法 请 读者 目 行 去 莹 坛 ， 思 想 
都 是 类 似 的 。 下 面 的 代码 在 大 约 1000ms 内 将 View 的 内 容 向 左 移 动 了 
100 像 素 ， 代 码 比 较 简 单 ， 束 不 再 详细 介绍 了 。 之 所 以 说 大 约 
1000ms， 是 因为 采用 这 种 方式 无 法 精确 地 定时 ， 原 因 是 系统 的 消 恩 调 
度 也 是 需要 时 间 的 ， 并 且 所 需 时 间 不 定 。 


private static final int MESSAGE_SCROLL_TO = 1; 
private static final int FRAME_COUNT = 30; 
private static final int DELAYED_TIME = 33; 
private int mCount = 0; 


@SuppressLint ("HandlerLeak" ) 


上 面 几 种 弹性 滑动 的 实现 方法 ， 在 介绍 中 侧重 更 多 的 是 实现 思 
想 ， 在 实际 使 用 中 可 以 对 其 灵活 地 进行 扩展 从 而 实现 更 多 复杂 的 效 
果 。 


34 View 的 事件 分 发 机 制 


上 面 儿 市 介绍 了 View 的 基础 知识 以 及 View 的 滑动 ， 本 市 将 介绍 
View 的 一 个 核心 知识 点 : 事件 分 发 机 制 。 事 件 分 发 机 制 不 仅仅 是 核心 
知识 点 更 是 难点 ， 不 少 初学 者 甚至 中 级 开发 者 面 对 这 个 问题 时 都 会 沉 
得 困惑 。 另 外 ，View 的 允 一 大 难题 请 动 冲突 ， 它 的 解决 方法 的 理论 基 
础 惑 是 事件 分 发 机 制 ， 因 此 和 车 握 好 View 的 事件 分 发 机 制定 十 分 重要 
的 。 本 市 将 深入 介绍 View 的 事件 分 发 机 制 ， 在 3.4.1 节 会 对 事件 分 发 机 
制 进行 概括 性 地 介绍 ， 而 在 3.4.2 市 将 结合 系统 源码 去 进一步 分 析 事 件 
分 发 机 制 。 


3.4.1 点击 事 件 的 传递 规则 


在 介绍 点 击 事件 的 传递 规则 之 前 ， 首 先 我 们 要 明白 这 里 要 分 析 的 
对 和 象 束 是 MotionEvent， 即 点 击 事件 ， 关 于 MotionEvent 在 3.1 节 中 已经 
进行 了 介绍 。 所 谓 点 击 事件 的 事件 分 发 ， 其 实 丈 是 对 MotionEvent 事 件 
的 分 发 过 程 ， 即 当 一 个 MotionEvent 产 生 了 以 后 ， 系 统 需 要 把 这 个 事件 
传递 给 一 个 具体 的 View， 而 这 个 传递 的 过 程 就 是 分 发 过 程 。 点 击 事件 
的 分 发 过 程 由 三 个 很 重要 的 方法 来 共同 完成 : dispatchTouchEvent ` 
onInterceptIouchEvent 和 onTouchEvent， 下 面 我 们 先 介绍 一 下 这 几 个 方 
Ke 


public boolean dispatchTouchEvent(MotionEvent ev) 


用 来 进行 事件 的 分 发 。 如 果 事 件 能 够 传递 给 当前 View， 那 么 此 方 
法 一 定 会 被 调用 ， 返 回 结果 受 当 前 View 的 onTouchEvent 和 下 级 View 的 


dispatchTouchEvent 方 法 的 影响 ， 表 示 是 否 消 耗 当前 事件 © 


public boolean onInterceptTouchEvent(MotionEvent event) 


在 上 述 方 法 内 部 调用 ， 用 来 判断 是 否 拦截 某 个 事件 ， 如 采 当 前 
View 拦 截 了 菏 个 事件 ， 那 么 在 同一 个 事件 序列 当中 ， 此 方法 不 会 被 再 
次 调用 ， 返 回 结 采 表示 是 否 拦截 当前 事件 。 


public boolean onTouchEvent(MotionEvent event) 


在 dispatchTouchEvent 方 法 中 调用 ， 用 来 处 理 点 击 事件 ， 返 回 结果 
表示 和 是否 消 耗 当 前 事件 ， 如 采 不 消耗 ， 则 在 同一 个 事件 序列 中 ， 当 前 
View 无 法 再 次 接收 到 事件 o 


上 述 三 个 方法 到 底 有 什么 区 别 呢 ? 它们 是 什么 关系 呢 ? 其 实 它 们 
的 关系 可 以 用 如 下 伪 代 码 表示 : 


public boolean dispatchTouchEvent(MotionEvent ev) { 
boolean consume = false; 
if (onInterceptTouchEvent(ev)) { 
consume = onTouchEvent(ev); 
) else { 
consume = child.dispatchTouchEvent (ev); 
} 
return consume; 


} 


上 述 伪 代码 已 经 将 三 者 的 关系 表现 得 淋漓 尽 致 。 通 过 上 面 的 伪 代 
码 ， 我 们 也 可 以 大 致 了 解 点 击 事件 的 传递 规则 : 对 于 一 个 根 


ViewGroup 来 说 ， 点 击 事件 产生 后 ， 首 先 会 传递 给 它 ， 这 时 它 的 
dispatchTouchEvent Wi & W YM FA, MR 这 个 ViewGroup 的 
onInterceptTouchEvent I 1212 Fltrueh KR EC BEES BSE, HAS 
件 束 会 交 给 这 个 ViewGroup 处 理 ， 即 它 的 onTouchEvent 方 法 就 会 被 调 
FA; 如 果 这 个 ViewGroup 的 onInterceptTouchEvent 方 法 返回 false 就 表示 
它 不 拦截 当前 事件 ， 这 时 当前 事件 瓯 会 继续 传递 给 它 的 子 元 素 ， 接 着 
子 元 素 的 dispatchTouchEvent 方 法 束 会 补 调 用 ， 如 此 反复 直到 事件 被 最 
终 处 理 。 


当 一 个 View 需 要 处 理事 件 时 ， 如 果 它 设置 了 OnTouchListener， 那 
么 OnTouchListener 中 的 onTouch 方 法 会 被 回调 。 这 时 事件 如 何 处 理 还 要 
看 onTouch 的 返回 值 ， 如 果 返 回 false， 则 当前 View 的 onTouchEvent 方 法 
会 被 调用 ;如 果 返 回 true， 那 么 onTouchEvent 方 法 将 不 会 被 调用 。 由 此 
可 见 ， 给 View 设 置 的 OnTouchListener， 其 优先 级 比 onTouchEvent 要 
高 。 在 onTouchEvent 方 法 中 ， 如 果 当 前 设置 的 有 OnClickListener， 那 么 
€ 的 onClick 方法 会 被 调用 。 可 以 看 出 ， 平时 我 们 常用 的 
OnClickListener， 其 优先 级 最 低 ， 即 处 于 事件 传递 的 尾 端 。 


当 一 个 点 击 事件 产生 后 ， 它 的 传递 过 程 遵循 如 下 顺序 : Activity -> 
Window -> View， 即 事件 总 是 先 传 递 给 Activity ，Activity 再 传递 给 
Window， 最 后 Window 再 传递 给 顶级 View。 顶级 View 接 收 到 事件 后 ， 
区 会 按照 事件 分 发 机 制 去 分 发 事件 。 考 虑 一 种 情况 ， 如 有 果 一 个 View 的 
onTouchEvent 返 回 false， 那 么 它 的 父 容 需 的 onTouchEvent 将 会 被 调用 ， 
依 此 类 推 。 如 果 所 有 的 元 素 都 不 处 理 这 个 事件 ， 那 么 这 个 事件 将 会 最 
终 传 递 给 Activity 处 理 ， 即 Activity 的 onTouchEvent 方 法 会 被 调用 。 这 个 
过 程 其 实 也 很 好 理解 ， 我 们 可 以 换 一 种 思路 ， 假 如 点 击 事件 是 一 个 难 
题 ， 这 个 难题 最 终 被 上 级 领导 分 给 了 一 个 程序 员 去 处 理 (这 是 事件 分 


RITTE) ， 结 果 这 个 程序 员 搞 不 定 (onTouchEventi [Al f false) , El 
在 该 怎么 办 呢 ? 难题 必须 要 解决 ， 那 只 能 交 给 水 平 更 高 的 上 级 解决 
(上 级 的 onTouchEvent 被 调用 ) ， 如 果 上 级 再 搞 不 定 ， 那 只 能 交 给 
级 的 上 级 去 解决 ， 丈 这样 将 难题 一 层 层 地 癌 上 抛 ， 这 是 公司 内 部 一 种 
很 常见 的 处 理 问题 的 过 程 。 从 这 个 角度 来 看 ，View 的 事件 传递 过 程 还 

是 很 贴近 现实 的 ， 毕 竟 程 序 员 也 生活 在 现实 中 。 


天 于 事件 传递 的 机 制 ， 这 里 给 出 一 些 结论 ， 根 据 这 些 结论 可 以 更 
好 地 理解 整个 传递 机 制 ， 如 下 所 示 。 


(1) 同一 个 事件 序列 是 指 从 手指 接触 屏幕 的 那 一 刻 起 ， 到 手指 离 
开 屏 幕 的 那 一 刻 结 束 ， 在 这 个 过 程 中 所 产生 的 一 系列 事件 ， 这 个 事件 
序列 以 down 事 件 开始 ， 中 间 含 有 数量 不 定 的 move 事 件 ， 最 终 以 up 事件 
结束 。 


(2) 正常 情况 下 ， 一 个 事件 序列 只 能 被 一 个 View 拦 截 且 消耗 。 
这 一 条 的 原因 可 以 参考 (3) ， 因 为 一 旦 一 个 元 素 拦截 了 某 此 事件 ， 那 
么 同一 个 事件 序列 内 的 所 有 事件 都 会 直接 交 给 它 处 理 ， 因 此 同一 个 事 
件 序列 中 的 事件 不 能 分 别 由 两 个 View 同 时 处 理 ， 但 是 通过 特殊 手段 可 
以 做 到 ， 比 如 一 个 View 将 本 该 目 己 处 理 的 事件 通过 onTouchEvent 强 行 
传递 给 其 他 View 处 理 。 


(3) 某 个 View 一 旦 决定 拦截 ， 那 么 这 一 个 事件 序列 都 只 能 由 它 
来 处 理 (如 果 事 件 序列 能 够 传递 给 它 的 话 ) ， 并 且 它 的 
onInterceptTouchEvent 不 会 再 被 调 用 。 这 条 也 很 好 理解 ， 就 是 说 当 一 个 
View 决 定 拦截 一 个 事件 后 ， 那 么 系统 会 把 同一 个 事件 序列 内 的 其 他 方 
法 都 直接 交 给 它 来 处 理 ， 因 此 束 不 用 再 调用 这 个 View 的 
onInterceptIouchEvent 去 询问 它 是 否 要 拦截 了 。 


(4) 某 个 View 一 旦 开始 处 理事 件 ， 如 果 它 不 消耗 
ACTION_DOWN 事 件 (onTouchEvent 返 回 了 false) ， 那 么 同一 事件 序 
列 中 的 其 他 事件 都 不 会 再 交 给 它 来 处 理 ， 并 且 事 件 将 重新 交 由 它 的 父 
元 素 去 处 理 ， 即 父 元 素 的 onTouchEvent 会 被 调用 。 意 思 了 就 是 事件 一 旦 
区 给 一 个 View 处 理 ， 那 么 它 瓯 必须 消耗 掉 ， 否 则 同一 事件 序列 中 剩 下 
的 事件 或 不 再 交 给 它 来 处 理 了 ， 这 就 好 比 上 级 交 给 程序 员 一 件 事 ， 如 
果 这 件 事 没有 处 理 好 ， 短 期 内 上 级 就 不 敢 再 把 事情 交 给 这 个 程序 员 做 
了 ， 二 者 是 类 似 的 道理 。 


(5) 如 果 View 不 消耗 除 ACTION_DOWN 以 外 的 其 他 事件 ， 那 么 
这 个 点 击 事件 会 消失 ， 此 时 父 元 素 的 onTouchEvent 并 不 会 被 调用 ， 并 
且 当 前 View 可 以 持续 收 到 后 续 的 事件 ， 最 终 这 些 消失 的 点 击 事件 会 传 
2 Activity4bEE o 


(6) ViewGroup 默 认 不 拦截 任何 事件 。Android 源 码 中 ViewGroup 
的 onInterceptTouch-Event 方 法 默认 返回 false ° 


(7) View 没 有 onInterceptTouchEvent 方 法 ， 一 旦 有 点 击 事 件 传递 
给 它 ， 那 么 它 的 onTouchEvent 方 法 开会 被 调用 。 


(8) View 的 onTouchEvent 默 认 都 会 消耗 事件 (返回 true) ， 除 非 
它 是 不 可 点 击 的 (dickable 和 longClickable 同 时 为 false) 。View 的 
longClickable 属 性 默认 都 为 false，clickable 属 性 要 分 情况 ， 比 如 Button 
的 clickable 属 性 默认 为 tue， 而 TextView 的 clickable 属 性 默认 为 false。 


(9) View 的 enable 属 性 不 影响 onTouchEvent 的 默认 返回 值 。 哪 怕 
一 个 View 是 disable 状 态 的 ， 只 要 它 的 clickable 或 者 longClickable 有 一 个 
为 ttue， 那 么 它 的 onTouchEvent 就 返回 true。 


(10) onClick 会 发 生 的 前 提 是 当前 View 是 可 点 击 的 ， 并 且 它 收 到 
了 down 和 up 的 事件 。 


(11) 事件 传递 过 程 是 由 外 向 内 的 ， 即 事件 总 是 先 传递 给 父 元 
素 ， 然 后 再 由 父 元 素 分 发 给 子 View ， 通 过 
requestDisallowInterceptTouchEvnt „AH UEF IA P FMRE 
事件 分 发 过 程 ， 但 是 ACTION_DOWN 事 件 除 外 。 


3.4.2 事件 分 发 的 源码 解析 


上 一 市 分 析 了 View 的 事件 分 发 机 制 ， 本 节 将 会 从 源码 的 角度 去 进 
一 步 分 析 、 证 实 上 面 的 结论 。 


1. Activity 对 点 击 事件 的 分 发 过 程 


点 击 事件 用 MotionEvent 来 表示 ， 当 一 个 点 击 操作 发 生 时 ， 事 件 最 
5c Fe 8 24 4 A Activity, H Activity HY dispatchTouchEvent3 vt 47 FF YR 
发 ， 具 体 的 工作 是 由 Activity 内 部 的 window 来 完成 的 。Window 会 将 事 
件 传递 给 decor view, decor view 一 般 就 是 当前 界面 的 底层 容器 (A 
setContentView 所 设置 的 View 的 父 容 器 ) ， 通 过 
Activity.getWindow.getDecorView() 可 以 获得 。 我 们 先 从 Activity 的 
dispatchTouchEvent 开 始 分 析 。 


YEM: Activity#dispatchTouchEvent 


public boolean dispatchTouchEvent(MotionEvent ev) { 
if (ev.getAction() == MotionEvent.ACTION_DOWN) { 


onUserInteraction(); 


Í 

if (getwindow().superDispatchTouchEvent(ev)) { 
return true; 

t 


return onTouchEvent(ev); 


} 


现在 分 析 上 面 的 代码 。 首 移 事 件 开 始 交 给 Activity 所 附属 的 
Window 进 行 分 发 ， 如 果 返 回 true， 整 个 事件 循环 束 结 束 了 ， 返 回 false 
意味 着 事件 没 人 处 理 ， 所 有 View 的 onTouchEvent 都 返回 了 false， 那 么 
Activity 的 onTouchEvent 束 会 被 调用 。 


接 下 来 看 Window 是 如 何 将 事件 传递 给 ViewGroup 的 。 通 过 源码 我 
们 知道 ，Window 是 个 抽象 类 ， 而 Window 的 superDispatchTouchEvent 方 
法 也 是 个 抽象 方法 ， 因 此 我 们 必须 找到 Window 的 实现 类 才 行 。 


源码 : Window#superDispatchTouchEvent 


public abstract boolean superDispatchTouchEvent(MotionEvent 


event); 


那么 到 底 Window 的 实现 类 是 什么 呢 ? 其 实 是 PhoneWindow， 这 一 
点 从 Window 的 源码 中 也 可 以 看 出 来 ， 在 Window 的 说 明 中 ， 有 这 人 么 一 
段 话 : 


Abstract base class for a top-level window look and behavior policy. 
An instance of this class should be used as the top-level view added to the 
window manager. It provides standard UI policies such as a background, 


title area, default key processing, etc. 


The only existing implementation of this abstract class is android. 
policy. PhoneWindow,which you should instantiate when needing a 
Window. Eventually that class will be refactored and a factory method 
added for creating Window instances without knowing about a particular 


implementation. 


上 面 这 段 话 的 大 概 意思 是 : Window 类 可 以 控制 顶级 View 的 外 观 和 
行为 贫 上 略 ， 它 的 唯一 实现 位 于 android.policy.PhoneWindow 中 ， 当 你 要 
实例 化 这 个 Window 类 的 时 候 ， a 因为 这 个 类 会 被 
重 构 ， 只 有 一 个 工 广 方法 可 以 使 用 。 尽 管 这 看 起 来 有 点 模糊 ， 不 过 我 
们 可 以 看 一 下 android.policy.PhoneWindow 这 个 类 ， 尽 管 实 例 化 的 时 候 
此 类 会 被 重 构 ， 仅 是 重 构 而 已 ， 功 能 是 类 似 的 。 


由 于 Window 的 唯一 实现 是 PhoneWindow , 此 接 下 来 看 一 下 
PhoneWindow 是 如 何 处 理 点 击 事件 的 ， 如 下 所 示 。 


源码 : PhoneWindow#superDispatchTouchEvent 


public boolean superDispatchTouchEvent(MotionEvent event) { 


return mDecor.superDispatchTouchEvent (event); 


到 这 里 逻辑 就 很 清晰 了 ，PhoneWindow 将 事件 直接 传递 给 了 
IX 


DecorView， 这 个 DecorView 是 什么 呢 ? 请 看 下 面 : 


private final class DecorView extends FrameLayout 
implements RootViewSur - 
faceTaker 


// This is the top-level view of the window, containing the 


window decor. 
private DecorView mDecor; 
@Override 
public final View getDecorView() { 
if (mDecor == null) { 
installDecor(); 
i 


return mDecor; 


} 


我 们 A El , i 过 
((ViewGroup)getWindow().getDecorView().findViewByld(android.R.id.co 
ntenb).getChildAt(0) 这 种 方式 瓯 可 以 获取 Activity 所 设置 的 View， 这 个 
mDecor 显 然 就 是 getWindow().getDecorView() 返 回 的 View， 而 我 们 通过 
setContentView 设 置 的 View 是 它 的 一 个 子 View。 目 前 事件 传递 到 了 
DecorView 这 里 ， 由 于 DecorView 继 承 目 FrameLayout 且 是 父 View， 所 
以 最 终 事件 会 传递 给 View。 换 句 话 来 说 ， 事 件 肯定 会 传递 到 View， 不 
然 应 用 如 何 响 应 点 击 事件 呢 ? 不 过 这 不 是 我 们 的 重点 ， 重 点 是 事件 到 
了 View 以 后 应 该 如 何 传递 ， 这 对 我 们 更 有 用 。 从 这 里 开始 ， 事 件 已 经 
传递 到 顶级 View 了 ， 即 在 Activity 中 通过 setContentView 所 设置 的 
View, 39 T View th MU FE View, MER View — AX HK it Ah E 


ViewGroup ° 


3. 顶级 View 对 点 击 事件 的 分 发 过 程 


天 于 点 击 事件 如 何在 View 中 进行 分 发 ， 上 一 市 已 经 做 了 详细 的 介 
这 里 再 大 致 回顾 一 下 。 点 击 事件 达到 顶级 View (一 般 是 一 个 
ViewGroup) 以 后 ， 会 调用 ViewGroup 的 dispatchTouchEvent 方 法 ， 然 后 


的 逻辑 是 这 样 的 : 如 果 顶 级 ViewGroup 拦截 事件 即 
onInterceptITouchEvent 返 回 true， 则 事件 由 ViewGroup 处 理 ， 这 时 如 采 
ViewGroup 的 mOnTouchListener 被 设置 ， 则 onTouch 会 被 调用 ， 否 则 
onTouchEvent 会 被 调用 。 也 融 是 说 ， 如 采 都 提供 的 话 ，onTouch 会 屏蔽 
掉 onTouchEvent。 在 onTouchEvent 中 ， 如 果 设 置 了 moOnClickListener ， 
则 onClick 会 被 调用 。 如 果 顶 级 ViewGroup 不 拦截 事件 ， 则 事件 会 传递 
给 它 所 在 的 点 击 事件 链 上 的 子 View， 这 时 子 View 的 dispatchTouchEvent 
会 被 调用 。 到 此 为 止 ， 事 件 已 经 从 顶级 View 传 递 给 了 下 一 层 View， 接 
下 来 的 传递 过 程 和 顶级 View 是 一 致 曲 ， 如 此 循环 ， 完 成 整个 事件 的 分 
发 o 


首先 看 ViewGroup 对 点 击 事件 的 分 发 过 程 ， 其 主要 实现 在 
ViewGroup 的 dispatchTouch-Event 方 法 中 ， 这 个 方法 比较 长 ， 这 里 分 段 
说 明 。 移 看 下 面 一 段 ， 很 显然 ， 它 描述 的 是 当前 View 是 否 拦截 点 击 事 


情 这 个 逻辑 。 


// Check for interception. 
final boolean intercepted; 
if (actionMasked == MotionEvent.ACTION_DOWN 
|| mFirstTouchTarget != null) { 
final boolean disallowIntercept = (mGroupFlags & 
FLAG_DISALLOW_ INTERCEPT) != 0; 
if (!disallowIntercept) { 
intercepted = onInterceptTouchEvent (ev); 
ev.setAction(action); // restore action in case 
it was changed 


} else { 


intercepted = false; 
} 
} else { 
// There are no touch targets and this action is not an 
initial down 
// so this view group continues to intercept touches. 
intercepted = true; 


} 


从 上 面 代码 我 们 可 以 看 出 ，ViewGroup 在 如 下 两 种 情况 下 会 判断 
是 否 要 拦截 当前 事件 : 事件 类 型 为 ACTION DOWN 或 者 
mFirstTouchTarget != null ° ACTION_DOWN 事件 好 理解 ， 那 么 
mFirstTouchTarget != null 是 什么 意思 呢 ? 这 个 从 后 面 的 代码 逻辑 可 以 
看 出 来 ， 当 事件 由 ViewGroup 的 子 元 素 成 功 处 理 时 ，mFirstTouchTarget 
会 被 赋值 并 指 癌 子 元 素 ， 换 种 方式 来 说 ， 当 ViewGroup 不 拦截 事件 并 
将 事件 交 由 子 元 素 处 理 时 mFirstTouchTarget != null。 反 过 来 ， 一 旦 事 
件 由 当前 ViewGroup 拦 截 时 ，mFirstTouchTarget != null 就 不 成 立 。 那 么 
当 ACTION_MOVE 和 ACTION_UP 事 件 到 来 时 ， 由 于 (actionMasked == 
MotionEvent. ACTION_DOWN || mFirstTouchTarget != null) 这 个 条 件 为 
false， 将 导致 ViewGroup 的 onInterceptIouchEvent 不 会 再 被 调用 ， 并 且 
同一 序列 中 的 其 他 事件 都 会 默认 交 给 它 处 理 。 


当然 ， 这 里 有 一 种 特殊 情况 WAE 
FLAG_DISALLOW_INTERCEPT 标记 位 ， 这 个 标记 位 是 通过 
requestDisallowInterceptTouchEvent 方 法 来 设置 的 ， 一 般 用 于 子 View 
中 。FLAG_DISALLOW_INTERCEPT 一 旦 设置 后 ，ViewGroup 将 无 法 
拦截 除了 ACTION_DOWN 以 外 的 其 他 点 击 事件 。 为 什么 说 是 除了 


ACTION_DOWN 以 外 的 其 他 事件 呢 ? 这 是 因为 ViewGroup 在 分 发 事件 
时  ， 如 RX 是 ACTION DOWN 就 会 E ÈE 
FLAG_DISALLOW_INTERCEPT 这 个 标记 位 ， 将 导致 子 View 中 设置 的 

这 个 标记 位 无 效 。 因 此 ， 当 面 对 ACTION_DOWN 事 件 时 ，ViewGroup 
总 是 会 调用 自己 的 onInterceptTouchEvent 方 法 来 询问 目 己 是 否 要 拦截 事 
件 ， 这 一 点 从 源码 中 也 可 以 看 出 来 。 在 下 面 的 代码 中 ，ViewGroup 会 
在 ACTION_DOWN 事件 到 来 时 做 重 置 状态 的 操作 ， 而 在 
resetTouchState 77 JE F & Xf FLAG _DISALLOW_INTERCEPT 进行 重 
置 ， 因 此 子 View 调 用 request-DisallowInterceptIouchEvent 方 法 并 不 能 影 
响 ViewGroup 对 ACTION_DOWN 事 件 的 处 理 。 


// Handle an initial down. 
if (actionMasked == MotionEvent.ACTION_DOWN) { 
// Throw away all previous state when starting a new 
touch gesture. 
// The framework may have dropped the up or cancel 
event for the previous gesture. 
// due to an app switch,ANR,or some other state change. 
cancelAndClearTouchTargets(ev); 


resetTouchState(); 


从 上 面 的 源码 分 析 ， 我 们 可 以 得 出 结论 : 当 ViewGroup 决 定 拦截 
(fla, BARS Sen 会 默认 交 给 它 处 理 并 且 不 再 调用 它 的 
onInterceptTouchEvent 方 法 ， 这 证 实 了 3.4.1 和 末尾 处 的 第 3 条 结论 。 
FLAG_DISALLOW_INTERCEPT 这 个 标志 的 作用 是 让 ViewGroup 不 再 
拦截 事件 ， 当 然 前 提 是 ViewGroup 不 拦截 ACTION_DOWN 事 件 ， 这 证 


实 了 3.4.1 节 末尾 处 的 第 11 条 结论 。 那 么 这 段 分 析 对 我 们 有 什么 价值 
We? 总 结 起 来 有 两 点 : 第 一 点 ，onInterceptTouchEvent 不 是 每 次 事件 都 
会 被 调用 的 ， 如 果 我 们 想 提 前 处 理 所 有 的 点 击 事件 ， 要 选择 
dispatchTouchEvent 方 法 ， 只 有 这 个 方法 能 确保 每 次 都 会 调用 ， 当 然 前 
提 是 事件 能 够 传递 到 当前 的 ViewGroup; 另外 一 点 ， 
FLAG_DISALLOW_INTERCEPT 标 记 位 的 作用 给 我 们 提供 了 一 个 思 
路 ， 当 面 对 滑 动 冲 突 时 ， 我 们 可 以 是 不 是 考虑 用 这 种 方法 去 解决 问 
题 ? 关于 消 动 冲突 ， 将 在 3.5 节 进行 详细 分 析 。 


接着 再 看 当 ViewGroup 不 拦截 事件 的 时 候 ， 事 件 会 向 下 分 发 交 由 
它 的 子 View 进 行 处 理 ， 这 段 源码 如 下 所 示 。 


final View[] children = mChildren; 
for (int i = childrenCount -1; i => 0; i--) { 
final int childIndex = customOrder 
? getChildDrawingOrder(childrenCount,i) : 1; 
final View child = (preorderedlist == null) 
? children[childIndex] 
preorderedList.get(childIndex) ; 


if (!canViewReceivePointerEvents(child) 


!isTransformedTouchPointInView(x,y,child,null)) { 
continue; 
$ 
newTouchTarget = getTouchTarget(child); 
if (newTouchTarget != null) { 


// Child is already receiving touch within its 


addTouchTarget(child, idBitsToAssign); 
alreadyDispatchedToNewTouchTarget = true; 


break; 


} 


上 面 这 段 代码 逻辑 也 很 清晰 ， 首 移 过 历 ViewGroup 的 所 有 子 元 
素 ， 然 后 判断 子 元 素 是 否 能 够 接收 到 点 击 事件 。 是 否 能 够 接收 点 击 事 
件 主 要 由 两 点 来 衡量 : 子 元 素 是 否 在 播 动 画 和 点 击 事件 的 坐标 是 否 落 
在 子 元 素 的 区 域内 。 如 果 某 个 子 元 素 满 足 这 两 个 条 件 ， 那 么 事件 就 会 
传递 给 它 来 处 理 。 可 以 看 到 ，dispatchTransformedTouchEvent 实 际 上 调 
用 的 就 是 子 元素 的 dispatchTouchEvent 方 法 ， 在 它 的 内 部 有 如 下 一 段 内 
容 ， 而 在 上 面 的 代码 中 child 传 递 的 不 是 null， 因 此 它 会 直接 调用 子 元 
素 的 dispatchTouchEvent 方 法 ， 这 样 事件 就 交 由 子 元 素 处 理 了 ， 从 而 完 
成 了 一 轮 事件 分 发 。 


if (child == null) { 
handled = super.dispatchTouchEvent (event); 
) else { 


handled = child.dispatchTouchEvent (event); 
} 


如 果子 元 素 的 dispatchTouchEvent 返 回 true， 这 时 我 们 暂时 不 用 考 
虚 事 件 在 子 元 于 内 部 是 怎么 分 发 的 ， 那 么 mFirstTouchTarget 束 会 被 赋 
值 同 时 跳出 for 循 环 ， 如 下 所 示 。 


newTouchTarget = addTouchTarget(child, idBitsToAssign); 


alreadyDispatchedToNewTouchTarget = true; 


break; 


这 几 行 代码 完成 了 mFirstTouchTarget 的 赋值 并 终止 对 子 元 素 的 通 
历 。 如 果子 元 素 的 dispatchTouchEvent 返 回 false，ViewGroup 就 会 把 事 
件 分 发 给 下 一 个 子 元 素 (如 果 还 有 下 一 个 子 元 素 的 话 ) 。 


其 实 mFirstTouchTarget 真 正 的 赋值 过 程 是 在 addTouchTarget 内 部 完 
成 的 ， 从 下 面 的 addTouchTarget 方法 的 内 部 结构 可 以 看 出 ， 
mFirstTouchTarget 其 实 是 一 种 单 链表 结构 。mFirstTouchTarget 是 否 被 赋 
值 ， 将 直接 影响 到 ViewGroup WEHEN ER RR, TR 
那么 ViewGroup 就 默认 拦截 接 下 来 同一 序列 
中 所 有 的 点 击 事件 ， 这 一 点 在 前 面 已 经 做 了 分 析 。 


private TouchTarget addTouchTarget(View child,int 
pointerIdBits) { 
TouchTarget target = 
TouchTarget.obtain(child, pointerIdBits); 
target.next = mFirstTouchTarget; 
mFirstTouchTarget = target; 


return target; 


} 
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情况 : 第 一 种 是 ViewGroup 没 有 子 元 素 ; 第 二 种 是 子 元 素 处 理 了 点 击 
事件 ， 但 是 在 dispatchTouchEvent 中 返回 了 false， 这 一 般 是 因为 子 元 丸 
在 a 了 false。 在 这 两 种 情况 下 ，ViewGroup 会 目 己 处 
理 点 击 事件 ， 这 里 束 证 实 了 3.4.1 季 中 的 第 4 条 结论 ， 代 码 如 下 所 示 。 


// Dispatch to touch targets. 
if (mFirstTouchTarget == null) { 
// No touch targets so treat this as an ordinary view. 
handled = 
dispatchTransformedTouchEvent(ev, canceled, null, 


TouchTarget.ALL_POINTER_IDS); 


注意 上 面 这 段 代 码 ， 这 里 第 三 个 参数 child 为 null， 全 前 而 的 人 PANT 

ae 它 会 调用 super.dispatchTouchEvent(event)， 很 显然 ， 这 里 就 

. 了 View 的 dispatchTouchEvent 方 法 ， 即 点 击 事件 开始 交 由 View 来 处 
， 请 看 下 面 的 分 析 。 


4. View 对 点 击 事件 的 处 理 过 程 


View 对 点 击 事件 的 处 理 过 程 稍 微 简 单一 些 ， 注 意 这 里 的 View 不 包 
售 ViewGroup。 先 看 它 的 dispatchTouchEvent 方 法 ， 如 下 所 示 。 


public boolean dispatchTouchEvent(MotionEvent event) { 


boolean result = false; 


if (onFilterTouchEventForSecurity(event)) { 
//noinspection SimplifiableIfStatement 
ListenerInfo li = mListenerInfo; 
if (li != null && 11.mOnTouchListener != null 
&& (mViewFlags € ENABLED MASK) 
== ENABLED 
&& 


1i.mOnTouchListener.onTouch(this,event)) { 
result = true; 
} 
if (!result && onTouchEvent(event)) { 


result = true; 


return result; 


i 


View 对 点 击 事件 的 处 理 过 程 就 比较 简单 了 ， 因 为 View (这 里 不 包 
E ViewGroup) 是 一 个 单独 的 元 素 ， 它 没有 子 元 素 因 此 无 法 同 下 传递 
事件 ， 所 以 它 只 能 自己 处 理事 件 。 从 上 面 的 源码 可 以 看 出 View 对 点 击 
事件 的 处 理 过 程 ， 首 移 会 判断 有 没有 设置 OnTouchListener AIR 
OnTouchListener 中 的 onTouch 方 法 返回 true， 那 么 onTouchEvent 就 不 会 
被 调用 ， 可 见 OnTouchListener 的 优先 级 高 于 onTouchEvent， 这 样 做 的 
好 处 是 方便 在 外 界 处 理 点 击 事件 。 


接着 再 分 析 onTouchEvent 的 实现 。 先 看 当 View 人 处 于 不 可 用 状态 下 
点 击 事件 的 处 理 过 程 ， 如 下 所 示 。 很 显然 ， 不 可 用 状态 下 的 View 照 样 
会 消耗 点 击 事件 ， 尽 管 它 看 起 来 不 可 用 。 


if ((viewFlags & ENABLED_MASK) == DISABLED) { 
if (event.getAction() == MotionEvent.ACTION_UP && 
(mPrivateFlags € PFLAG_PRESSED) != 0) { 


setPressed(false); 


接着 ， 如 果 View 设 置 有 代理 ， 那 么 还 会 执行 TouchDelegate 的 
onTouchEvent 方法 ， 这 个 onTouchEvent 的 工作 机 制 看 起 来 和 
OnTouchListener 类 似 ， 这 里 不 深入 人 研究 了 。 


下 面 再 看 一 下 onTouchEvent 中 对 点 击 事件 的 具体 处 理 ， 如 下 所 
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从 上 面 的 代码 来 看 ， 只 要 View 的 CLICKABLE 和 
LONG_CLICKABLE 有 一 个 为 tue， 那 么 它 就 会 消耗 这 个 事件 ， 即 
onTouchEvent 方 法 返回 true， 不 管 它 是 不 是 DISABLE 状 态 ， 这 就 证 实 
了 3.4.1 节 末尾 处 的 第 8、 第 9 和 第 10 条 结论 。 然 后 就 是 当 ACTION_UP 
事件 发 生 时 ， 会 触发 performClick 方 法 ， 如 果 View 设 置 了 
OnClickListener， 那 么 performClick 方 法 内 部 会 调用 它 的 onClick 方 法 ， 
如 下 所 示 。 


sendAccessibilityEvent (AccessibilityEvent.TYPE_VIEW_CLICKED); 


return result; 


View 的 LONG_CLICKABLE 属 性 默认 为 false， 而 CLICKABLE 属 性 
© T X false A AM View E X, HUREN SG MN View 其 
CLICKABLE Y true, TH] at AY View È CLICKABLE W false, EG 4 
Button 是 可 上 点击 的 ，TextView 是 不 可 点 击 的 。 通 过 setClickable 和 
setLongClickable 可 A ap Al W Æ View 的 CLICKABLE 和 
LONG_CLICKABLE 属 性 。 男 外 ，setOnClickListener 会 自动 将 View 的 
CLICKABLE 设 为 true , os 则 会 自动 将 View 的 
LONG_CLICKABLE 设 为 tue， 这 一 点 从 源码 中 可 以 看 出 来 ， 如 下 所 
ie 


public void setOnClickListener(OnClickListener 1) { 
if (!isClickable()) { 
setClickable(true); 
} 
getListenerInfo().mOnClickListener = 1; 
} 
public void setOnLongClickListener(OnLongClickListener 1) { 
if (!isLongClickable()) { 
setLongClickable(true); 


getListenerInfo().mOnLongClickListener = 1; 


} 


到 这 里 ， 点 击 事件 的 分 发 机 制 的 源码 实现 已 经 分 析 完 了 ， 结 合 
3.4.1 廊 中 的 理论 分 析 和 相关 结论 ， 读 者 就 可 以 更 好 地 理解 事件 分 发 
了 。 在 3.5 廊 将 介绍 滑动 冲突 相关 的 知识 ， 具 体 情 况 请 看 下 面 的 分 析 。 
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ANTI FT YR TT A View (RAP MAAN aR: 滑动 冲突 。 相 信 开 发 
Android 的 人 都 会 有 这 种 体会 : HIMRTERRHINT , ARME 
下 载 的 demo 运 行 得 好 好 的 ， 但 是 只 要 出 现 滑动 冲突 ，demo 融 无 法 正常 
工作 了 。 那 么 滑动 冲突 是 如 何 产 生 的 呢 ? 其 实在 界面 中 只 要 内 外 两 层 
同时 可 以 滑动 ， 这 个 时 候 就 会 产生 滑动 冲突 。 如 何 解 决 滑动 冲突 呢 ? 
这 既是 一 件 困 难 的 事 又 征 一 件 简单 的 事 ， 说 困难 是 因为 许多 开发 者 面 
对 滑动 冲突 都会 显得 束手无策 ， 说 简单 古 因 为 滑动 冲突 的 解决 有 固定 
的 套路 ， 只 要 知道 了 这 个 固定 套路 问题 惑 好 解决 了 。 本 节 征 View 体 系 
的 核心 章 订 ， 前 面 4 广 均 是 为 本 市 服务 的 ， 通 过 本 市 的 学 习 ， 渭 动 冲 突 
将 不 再 是 个 问题 。 


3.5.1 FABRE 


常见 的 滑动 冲突 场景 可 以 简单 分 为 如 下 三 种 (详情 请 参看 图 3- 
4) : 


[ 局 
— 


场景 1 场景 2 


图 3-4 滑动 冲突 的 场景 


。 场景 1] 一 一 外 部 请 动 方向 和 内 部 滑动 方 癌 不 一 致 
。 场景 2 一 一 外 部 裤 动 方向 和 内 部 滑动 方 网 一致; 


。 场景 3 一 一 上 面 两 种 情况 的 嵌 套 。 


先 说 场景 1， 主 要 是 将 ViewPager 和 Fragment 配 合 使 用 所 组 成 的 页 
面 滑 动 效 采 ， 主 流 应 用 几乎 都 会 使 用 这 个 效果 。 在 这 种 效果 中 ， 可 以 
通过 左右 请 动 来 切换 页 面 ， 而 每 个 页 面 内 部 往往 又 是 一 个 ListView 。 
本 来 这 种 情况 下 是 有 清 动 神 突 鸭 ， 但 是 ViewPager 内 部 处 理 了 这 种 滑动 
冲突 ， 因 此 采用 ViewPager 时 我 们 无 须 关 注 这 个 问题 ， 如 果 我 们 采用 的 
不 是 ViewPager 而 是 ScrollView 等 ， 那 就 必须 手动 处 理 消 动 冲突 了 ， 否 
则 造成 的 后 果 束 是 内 外 两 层 只 能 有 一 层 能 够 滑动 ， 这 是 因为 两 者 之 间 
的 滑动 事件 有 冲突 。 除 了 这 种 典型 情况 外 ， 还 存在 其 他 情况 ， 比 如 外 
部 上 下 请 动 、 内 部 左右 滑动 等 ， 但 是 它们 属于 同一 类 请 动 冲突 。 


再 说 场景 2， 这 种 情况 束 稍 微 复 杂 一 些 ， 当 内 外 两 层 都 在 同一 个 方 
癌 可 以 滑动 的 有 时候， 显然 存在 逻辑 问题 。 因 为 当 手 指 开始 滑动 的 时 
候 ， 系 统 无 法 知道 用 户 到 底 是 想 让 哪 一 层 消 动 ， 所 以 当 手 指 滑动 的 时 
候 训 会 出 现 问 题 ， 要 么 只 有 一 层 能 滑动 ， 要 么 吏 是 内 外 两 层 都 滑动 得 
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最 后 说 下 场景 3， 场 景 3 是 场景 1 和 场景 2 两 种 情况 的 能 均 ， 因 此 场 
景 3 的 滑动 冲突 看 起 来 惑 更 加 复杂 了 “。 比 如 在 许多 应 用 中 会 有 这 人 么 一 个 
效果 : 内 层 有 一 个 场景 1 中 的 滑动 效果 ， 然 后 外 层 又 有 一 个 场景 2 中 的 
滑动 效果 。 上 有 具体 说 惑 是 ， 外 部 有 一 个 SlideMenu 效 末 ， 然 后 内 部 有 一 个 
ViewPager，ViewPager 的 每 一 个 页 面 中 又 是 一 个 ListView。 虽然 说 场景 
3 的 滑动 冲突 看 起 来 更 复杂 ， 但 是 它 是 几 个 单一 的 请 动 冲突 的 三 加 ， 因 
此 只 需要 分 别处 理 内 层 和 中 层 、 中 层 和 外 层 之 间 的 背 动 冲突 即 可 ， 而 
具体 的 处 理 方法 其 实 是 和 场景 1、 场 景 2 相同 的 。 


从 本 质 上 来 说 ， 这 三 种 滑动 冲突 场景 的 复杂 上 度 其 实 是 相同 的 ， 
为 它们 的 区 别 仅 仅 古 滑动 策略 的 不 同 ， 至 于 解决 消 动 冲突 的 方法 ， 它 
们 几 个 是 通用 的 ， 在 3.5.2 世 中 将 会 详细 介绍 这 个 问题 。 


3.5.2 ”请 动 冲突 的 处 理 规则 


一 般 来 说 ,不管 消 动 冲突 多 么 复杂 ， 它 者 有 了 既定 的 规则 ， 根 据 这 
些 规则 我 们 就 可 以 选择 合适 的 方法 去 处 理 。 


如 图 3-4 所 示 ， 对 于 场景 1， 它 的 处 理 规 则 是 : 当 用 户 左 右 滑动 
时 ， 需 要 让 外 部 的 View 拦 截 点 击 事件 ， 当 用 户 上 下 滑动 时 ， 需 要 让 内 
部 View 拦 截 点 击 事件 。 这 个 时 候 我 们 就 可 以 根据 它们 的 特征 来 解决 消 
动 冲突 ， 具 体 来 说 是 : 根据 滑动 是 水 平滑 动 还 是 坚 直 消 动 来 判断 到 展 
由 谁 来 拦截 事件 ， 如 图 3-5 所 示 ， 根 据 滑 动 过 程 中 两 个 点 之 间 的 坐标 可 
可 以 得 出 到 展 是 水 平滑 动 还 是 坚 直 滑动 。 如 何 根据 坐标 来 得 到 请 动 的 
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平方 同 所 形成 的 夹 角 ， 也 可 以 依据 水 平方 同和 竖 直 方向 上 的 距离 差 来 
判断 ， 某 些 特殊 时 候 还 可 以 依据 水 平和 坚 直 方 同 的 速度 过 来 做 判断 。 
这 里 我 们 可 以 通过 水 平和 坚 直 方 癌 的 距离 演 来 判断 ， 比 如 罕 直 方 同 滑 
动 的 距离 大 束 判 断 为 坚 直 滑动 ， 否 则 判断 为 水 平 渭 动 。 根 据 这 个 规则 
束 可 以 进行 下 一 步 的 解决 方法 制定 了 。 


起 点 dx 


图 3-5 ”滑动 过 程 示意 


对 于 场景 2 来 说 ， 比 较 特 殊 ， 它 无 法 根据 请 动 的 角度 、 距 离 关 以 及 
速度 老 来 做 判断 ， 但 是 这 个 时 候 一 般 都 能 在 业务 上 找到 突破 点 ， 比 如 
业务 上 有 规定 : 当 处 于 某 种 状态 时 需要 外 部 View 啊 应 用 户 的 请 动 ， 而 
处 于 另外 一 种 状态 时 则 需要 内 部 View 来 响应 View 的 滑动 ， 根 据 这 种 业 
务 上 的 需求 我 们 也 能 得 出 相应 的 处 理 规则 ， 有 了 处 理 规则 同样 可 以 进 
行 下 一 步 处 理 。 这 种 场景 通过 文字 描述 可 能 比较 抽象 ， 在 下 一 节 会 通 
过 实际 的 例子 来 演示 这 种 情况 的 解决 方 条 ， 那 时 整容 易 理解 了 ， 这 里 
先 有 这 个 概念 即 可 。 


对 于 场景 3 来 说 ， 它 的 裤 动 规则 束 更 复杂 了 ， 和 场景 2 一 样 ， 它 也 
无 法 直接 根据 滑动 的 角度 、 距 离 关 以 及 速度 关 来 做 判断 ， 同 样 还 是 只 
能 从 业务 上 找到 突破 点 ， 具 体 方法 和 场景 2 一 样 ， 都 是 从 业务 的 需求 上 
得 出 相应 的 处 理 规则 ， 在 下 一 节 将 会 通过 实际 的 例子 来 演示 这 种 情况 
的 解决 方案 。 


3.5.3 TROPA I 
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析 各 种 场景 并 给 出 具体 的 解决 方法 。 首 先 我 们 要 分 析 第 一 种 渭 动 冲 突 
场景 ， 这 也 是 最 人 简单、 最 典型 的 一 种 滑动 冲突 ， 因 为 它 的 立 动 规则 比 
较 简 单 ， 不 管 多 复杂 的 滑动 冲突 ， 它 们 之 间 的 区 别 仅仅 是 滑动 规则 不 
同 而 已 。 抛 开 滑 动 规则 不 说 ， 我 们 需要 找到 一 种 不 依赖 具体 的 渭 动 规 
则 的 通用 的 解决 方法 ， 在 这 里 ， 我 们 束 根 据 场景 1 的 情况 来 得 出 通用 的 
解决 方案 ， 然 后 场景 2 和 场景 3 我 们 只 需要 修改 有 关 消 动 规则 的 逻辑 即 
Ho 
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景 1 中 的 效果 ， 我 们 不 需要 手动 处 理 请 动 冲突 ， 因 为 ViewPager 已 经 帮 
我 们 做 了 ， 但 是 这 里 为 了 更 好 地 演示 滑动 冲突 的 解决 思想 ， 没 有 采用 
ViewPager。 其 实在 滑动 过 程 中 得 到 请 动 的 角度 这 个 征 相 当 人 简单 的 ， 但 
征 到 撒 要 怎么 做 才能 将 点 击 事件 交 给 合适 的 View 去 处 理 呢 ? ARE 
用 到 3.4 市 所 讲述 的 事件 分 发 机 制 了 。 针 对 滑动 冲突 ， 这 里 给 出 两 种 解 
决 滑动 冲突 的 方式 : 外 部 拦截 法 和 内 部 拦截 法 。 


1. 外 部 拦截 法 


所 谓 外 部 拦截 法 是 指点 击 事情 都 移 经 过 父 容 器 的 拦截 处 理 ， 如 果 
父 容器 需要 此 事件 惑 拦截， 如 果 不 需要 此 事件 就 不 拦截 ， 这 样 就 可 以 
解决 滑动 冲突 的 问题 ， 这 种 方法 比较 符合 点 击 事件 的 分 发 机 制 。 外 部 
拦截 法 需要 重 写 父 容器 的 onInterceptTouchEvent 方 法 ， 在 内 部 做 相应 的 
拦截 即 可 ， 这 种 方法 的 伪 代 码 如 下 所 示 。 


default: 

break; 
} 
mLastXIntercept = x; 
mLastYIntercept = y; 
return intercepted; 


} 


上 述 代 码 是 外 部 拦截 法 的 典型 逻辑 ， 针 对 不 同 的 请 动 冲突 ， 只 需 
要 修改 父 容器 需要 当前 点 击 事件 这 个 条 件 即 可 ， 其 他 均 不 需 做 修改 并 
且 也 不 能 修改 。 这 里 对 上 述 代 码 再 描述 一 下 ， 在 onInterceptITouchEvent 
方法 中 ， 首 先是 ACTION_DOWN 这 个 事件 ， 父 容器 必须 返回 false， 即 
不 拦截 ACTION_DOWN 事 件 ， 这 是 因为 一 旦 父 容器 拦截 了 
ACTION_DOWN， 那 么 后 续 的 ACTION_MOVE 和 ACTION_UP 事 件 都 
会 直接 交 由 父 容器 处 理 ， 这 个 时 候 事 件 没 法 再 传递 给 子 元 素 了 ; 其 次 
是 ACTION_MOVE 事 件 ， 这 个 事件 可 以 根据 需要 来 决定 是 否 拦截 ， 如 
果 父 容器 需要 拦截 就 返回 true， 否 则 返回 false; 最 后 是 ACTION_UP 事 
件 ， 这 里 必须 要 返回 false， 因 为 ACTION_UP 事 件 本 身 没有 太 多 意义 。 


考虑 一 种 情况 ， 假 设 事件 交 由 子 元 素 处 理 ， 如 果 父 容器 在 
ACTION_UP 时 返回 了 true， 束 会 导致 子 元 素 无 法 接收 到 ACTION_UP 
事件 ， 这 个 时 候 子 元 素 中 的 onClick 事 件 就 无 法 触发 ， 但 是 父 容器 比较 
特殊 ， 一 旦 它 开始 拦截 任何 一 个 事件 ， 那 么 后 续 的 事件 都 会 交 给 它 来 
处 理 ， 而 ACTION_UP 作 为 最 后 一 个 事件 也 必定 可 以 传递 给 父 容器 ， 
即便 父 容器 的 onInterceptTouchEvent 方 法 在 ACTION_UP 时 返回 了 


false ° 


2. 内 部 拦截 法 
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元 素 ， 如 果子 元 素 需 要 此 事件 就 直接 消耗 挤 ， 否 则 就 交 由 父 容器 进行 
处 理 ， 这 种 方法 和 Android 中 的 事件 分 发 机 制 不 一 致 ， 需 要 配合 
requestDisallowInterceptTouchEvent 方 法 才能 正常 工作 ， 使 用 起 来 较 外 
部 拦截 法 稍 显 复 杂 。 它 的 伪 代 码 如 下 ， 我 们 需要 重 写 子 元 素 的 
dispatchTouchEvent 方 法 : 


} 

default: 
break; 

} 

mLastX = x; 

mLastY = y; 


return super.dispatchTouchEvent (event); 


} 


上 述 代 码 是 内 部 拦截 法 的 典型 代码 ， 当 面 对 不 同 的 请 动 策略 时 只 
需要 修改 里 面 的 条 件 即 可 ， 其 他 不 需要 做 改动 而 且 也 不 能 有 改动 。 除 
了 子 元 素 需 要 做 处 理 以 外 ， 父 元 素 也 要 默认 拦截 除了 ACTION_DOWN 
以 外 的 其 他 事件 ， 这 样 当 子 元 到 调用 parent.requestDisal- 
lowInterceptTouchEvent(false) 方 法 时 ， 父 元 素 才 能 继续 拦截 所 需 的 事 
件 。 


为 什么 父 容 器 不 能 拦截 ACTION_DOWN 事 件 呢 ? 那 是 因为 
ACTION_DOWN 事 件 并 不 受 FLAG_DISALLOW_INTERCEPT 这 个 标 
记 位 的 控制 ， 所 以 一 旦 父 容 器 拦截 ACTION_DOWN 事 件 ， 那 么 所 有 的 
事件 都 无 法 传递 到 子 元 素 中 去 ， 这 样 内 部 拦截 融 无 法 起 作用 了 。 父 元 
素 所 做 的 修改 如 下 所 示 。 


public boolean onInterceptTouchEvent(MotionEvent event) { 
int action = event.getAction(); 
if (action == MotionEvent.ACTION_DOWN) { 
return false; 
) else { 


return true; 


} 


下 面 通过 一 个 实例 来 分 别 介 绍 这 两 种 方法 。 我 们 来 实现 一 个 类 似 
于 ViewPager 中 岁 套 ListView 的 效果 ， 为 了 制造 消 动 冲突 ， 我 们 写 一 个 
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控件 的 具体 实现 思想 会 在 第 4 章 进 行 详细 介绍 ， 这 里 只 讲述 请 动 冲突 的 


部 分 。 


为 了 实现 ViewPager 的 效果 ， 我 们 定义 了 一 个 类 似 于 水 平 的 
LinearLayout 的 东西 ， 只 不 过 它 可 以 水 平滑 动 ， 初 始 化 时 我 们 在 它 的 内 
部 添加 若干 个 ListView， 这 样 一 来 ， 由 于 它 内 部 的 Listview 可 以 竖 直 消 
动 。 而 它 本 身 又 可 以 水 平滑 动 ， 因 此 一 个 典型 的 滑动 冲突 场景 就 出 现 
了 ， 并 且 这 种 冲突 属于 类 型 1 的 冲突 。 根 据 滑动 策略 ， 我 们 可 以 选择 水 
平和 竖 直 的 请 动 距离 差 来 解决 滑动 冲突 。 


目 先 来 看 一 下 Activity 中 的 初始 化 代码 ， 如 下 所 示 。 


public class DemoActivity_1 extends Activity { 

private static final String TAG = "SecondActivity"; 

private HorizontalScrollViewEx mListContainer; 

@Override 

protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.demo_1); 
Log.d(TAG, "onCreate"); 


initView(); 


ListView listView = (ListView) 
layout.findViewById(R.id.list); 
ArrayList<String> datas = new ArrayList<String>(); 
fOr (INE t= 0, 352.50, E) 


datas.add("name " + i); 


ArrayAdapter<String> adapter = new 


ArrayAdapter<String>(this, 


R.layout.content_list_item,R.id.name, datas); 


listView.setAdapter (adapter); 


EMI ORAS TR AA, ie BE Y 3/PListview? + H 4EListView 
加 入 到 我 们 自 定义 的 HorizontalScrollViewEx F , 这 里 
HorizontalScrollViewEx 是 父 容 絮 ， 而 ListView 则 是 子 元 素 ， 这 里 就 不 
再 多 介绍 了 。 


首先 采 用 外 部 拦截 法 来 解决 这 个 问题 ， 按 照 前 面 的 分 析 ， 我 们 只 
需要 修改 父 容 絮 需要 拦截 事件 的 条 件 即 可 。 对 于 本 例 来 说 ， 父 容器 的 
拦截 条 件 就 是 滑动 过 程 中 水 平 距 离 差 比 竖 直 距 离 差 大 ， 在 这 种 情况 
下 ， 父 容器 就 拦截 当前 点 击 事件 ， 根 据 这 一 条 件 进 行 相应 修改 ， 修 改 
后 的 HorizontalScrollViewEx 的 onInterceptIouchEvent 方 法 如 下 所 示 。 


public boolean onInterceptTouchEvent(MotionEvent event) { 
boolean intercepted = false; 


int x = (int) event.getX(); 


Log.d(TAG, "intercepted=" + intercepted); 
mLastXIntercept = x; 
mLastYIntercept = y; 
return intercepted; 


} 


从 上 面 的 代码 来 看 ， 它 和 外 部 拦截 法 的 伪 代 码 的 差别 很 小 ， 只 是 
把 父 容 絮 的 拦截 条 件 换 成 了 具体 的 逻辑 。 在 滑动 过 程 中 ， 当 水 平方 癌 
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ListView， 所 以 ListView 也 能 上 下 滑动 ， 如 此 滑动 冲突 就 解决 了 。 至 于 
mScroller.abortAnimation() 这 一 句 话 主要 是 为 了 优化 滑动 体验 而 加 入 
的 。 


考虑 一 种 情况 ， 如 果 此 时 用 户 正 在 水 平滑 动 ， 但 是 在 水 平滑 动 售 
止 之 前 如 果 用 户 再 迅速 进行 坚 直 滑动 ， 束 会 导致 界面 在 水 平方 向 无 法 
滑动 到 终点 从 而 处 于 一 种 中 间 状 在。 为 了 避免 这 种 不 好 的 体验 ， 当 水 
平方 同 正 在 滑动 时 ， 下 一 个 序列 的 点 击 事件 仍然 交 给 父 容 紫 处 理 ， 这 
样 水 平方 向 束 不 会 停留 在 中 间 状 态 了 。 


下 面 是 HorizontalScrollViewEx 的 具体 实现 ， 只 展示 了 和 消 动 冲突 
相关 的 代码: 


public class HorizontalScrollViewEx extends ViewGroup { 
private static final String TAG = 
"HorizontalScrollViewEx"; 
private int mChildrenSize; 


private int mChildwidth; 


如 果 采 用 内 部 拦截 法 也 是 可 以 的 ， 按 照 前 面 对 内 部 拦截 法 的 分 
析 ， 我 们 只 需要 修改 ListView 的 dispatchTouchEvent 方 法 中 的 父 容器 的 
拦截 逻辑 ， 同 时 让 父 容器 拦截 ACTION_MOVE 和 ACTION_UP 事 件 即 
可 。 为 了 重 写 ListView 的 dispatchTouchEvent 方 法 ， 我 们 必须 自 定义 一 
个 ListView， 称 为 ListViewEx， 然 后 对 内 部 拦截 法 的 模板 代码 进行 修 
改 ， 根 据 需 要 ，ListViewEx 的 实现 如 下 所 示 。 


RT E EX} ListView Pr fit ay EN, 我们 还 需要 修改 
HorizontalScrollViewEx 的 onInte-rceptIouchEvent 方 法 ， 修 改 后 的 类 和 暂 
且 叫 HorizontalScrollViewEx2 ， # onInterceptTouchEvent 77 7% WH F Pr 
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上 面 的 代码 区 是 内 部 拦截 法 的 示例 ， 其 中 
mScroller.abortAnimation() 这 一 句 不 是 必须 的 ， 在 当前 这 种 情形 下 主要 
是 为 了 优化 滑动 体验 。 从 实现 上 来 看 ， 内 部 拦截 法 的 操作 要 稍微 复杂 
一 些 ， 因 此 推荐 采用 外 部 拦截 法 来 解决 常见 的 滑动 冲突 。 


前 面 说 过 ， 只 要 我 们 根据 场景 1 的 情况 来 得 出 通用 的 解决 方案 ， 那 
么 对 于 场景 2 和 场景 3 来 说 我 们 只 需要 修改 相关 消 动 规则 的 有 逻辑 即 可 ， 
下 面 我 们 束 来 演示 如 何 利 用 场景 1 得 出 的 通用 的 解决 方案 来 解决 更 复杂 
的 清 动 冲突 。 这 里 只 详细 分 析 场 景 2 中 的 滑动 冲突 ， 对 于 场景 3 中 的 县 
加 型 消 动 冲突 ， 由 于 它 可 以 拆 解 为 单一 的 渭 动 冲突 ， 所 以 其 滑动 冲突 
的 解决 思想 和 场景 1、 场 景 2 中 的 单一 滑动 冲突 的 解决 思想 一 致 ， 只 需 
要 分 别 解 决 每 层 之 间 的 滑动 冲突 即 可 ， 再 加 上 本 书 的 篇 幅 有 限 ， 这 里 
束 不 对 场景 3 进行 详细 分 析 了 。 


对 于 场景 2 来 说 ， 它 的 解决 方法 和 场景 1 一 样 ， 只 是 渭 动 规则 不 同 
而 已 ， 在 前 面 我 们 已 经 得 出 了 通用 的 解决 方案 ， 因 此 这 里 我 们 只 需要 
蔡 换 父 容 右 的 拦截 规则 即 可 。 注 意 ， 这 里 不 再 演示 如 何 通 过 内 部 拦截 
法 来 解决 场景 2 中 的 滑动 冲突 ， 因 为 内 部 拦截 法 没有 外 部 拦截 法 简单 易 
用 ， 所 以 推荐 采用 外 部 拦截 法 来 解决 常见 的 滑动 冲突 。 


下 面 通过 一 个 实际 的 例子 来 分 析 场 景 2， 首 先 我 们 提供 一 个 可 以 上 
下 滑动 的 父 容器 ， 这 里 就 叫 StickyLayout， 它 看 起 来 束 像 是 可 以 上 下 消 
动 的 竖 直 的 LinearLayout， 然 后 在 它 的 内 部 分 别 放 一 个 Header 和 一 个 
ListView， 这 样 内 外 两 层 都 能 上 下 滑动 ， 于 是 就 形成 了 场景 2 中 的 滑动 
冲突 了 。 当 然 这 个 StickyLayout 是 有 请 动 规则 的 : 当 Header 显 示 时 或 者 
ListView 请 动 到 顶部 时 ， 由 StickyLayout 拦 截 事件 ， 当 Header 隐 藏 时 ， 
这 要 分 情况 ， 如 有 果 ListView 已 经 滑动 到 顶部 并 有 旦 当前 手势 是 癌 下 消 动 
的 话 ， 这 个 时 候 还 是 StickyLayout 拦 截 事件 ， 其 他 情况 则 由 ListView 拦 
截 事件 。 这 种 滑动 规则 看 起 来 有 点 复杂 ， 为 了 解决 它们 之 间 的 涓 动 剖 
突 ， 我 们 还 是 需要 重 写 父 容器 StickyLayout 的 onInterceptTouchEvent 方 
法 ， 至 于 ListView 则 不 用 做 任何 修改 ， 我 们 来 看 一 下 StickyLayout 的 具 
体 实现 ,滑动 冲突 相关 的 主要 代码 如 下 所 示 。 


从 上 面 的 代码 来 看 ， 这 个 StickyLayout 的 实现 有 点 复杂 ， 在 第 4 章 
会 详细 介绍 这 个 自 定 义 View 的 实现 思想 ， 这 里 先 有 大 概 的 印象 即 可 。 
下 面 我 们 主要 看 它 的 onIntercept-TouchEvent 方 法 中 对 ACTION_MOVE 
的 处 理 ， 如 下 所 示 。 


break; 


} 


我 们 来 分 析 上 面 这 段 代码 的 逻辑 ， 这 里 的 父 容器 是 StickyLayout， 

子 元 素 是 ListView。 首 先 ， 当 事件 落 在 Header 上 面 时 父 容器 不 会 拦截 
SF, 接着， 如 采 竖 直 距 离 差 小 于 水 平 距离 差 ， 那 么 父 容器 也 不 会 迫 
截 事件 ， 人 然后， 当 Header 是 展开 状态 并 且 辣 上 消 动 时 父 容 絮 拦截 事 
件 。 男 外 一 种 情况 ， 当 ListView 滑 动 到 顶部 了 并 且 癌 下 滑动 时 ， 父 容 
怖 也 会 拦截 事件 ， 经 过 这 些 层 层 判断 惑 可 以 达到 我 们 想 要 的 效果 了 。 
另外 ，giveUpTouchEvent 是 一 个 接口 方法 ， 由 外 部 实现 ， 在 本 例 中 主 
要 是 用 来 判断 ListView 是 否 滑动 到 顶部 ， 它 的 具体 实现 如 下 : 


public boolean giveUpTouchEvent(MotionEvent event) { 


if (expandableListView.getFirstVisiblePosition() == 0) 


View view = expandableListView.getChildAt(0); 
if (view != null && view.getTop() => 0) { 


return true; 


} 


return false; 


} 


上 面 这 个 例子 比较 复 杀 ， 需 要 读者 多 多 体会 其 中 的 写法 和 思想 。 
到 这 里 滑动 冲突 的 解决 方法 就 介绍 完毕 了 ， 至 于 场景 3 中 的 衫 动 冲突 ， 
利用 本 世 所 给 出 的 通用 的 方法 是 可 以 轻松 解决 的 ， 读 者 可 以 目 己 练习 
一 下 。 在 第 4 革 会 介绍 View 的 压 层 工作 原理 ， 并 且 会 介绍 如 何 写 出 一 
个 好 的 目 定 义 View。 同 时 ， 在 本 世 中 所 提 到 的 两 个 目 定义 View: 


Horizontal-ScrollViewEx 和 StickyLayout 将 会 在 第 4 章 中 进行 详细 的 介 
绍 ， 它 们 的 完整 源码 请 查看 本 书 所 提供 的 示例 代码 。 


第 4 章 ”View 的 工作 原理 


在 本 章 中 主要 介绍 两 方面 的 内 容 ， 首 移 介绍 View 的 工作 原理 ， 接 
着 介绍 目 定义 View 的 实现 方式 。 在 Android 的 知识 体系 中 ，View 扮 演 
着 很 重要 的 角色 ， 简 单 来 理解 ，View 是 Android 在 视觉 上 的 呈现 。 在 界 
面 上 Android 提 供 了 一 套 GUI 库 ， 里 面 有 很 多 控件 ， 但 是 很 多 时 候 我 们 
并 不 满足 于 系统 提供 的 控件 ， 因 为 这 样 就 意味 这 应 用 界面 的 同类 化 比 
较 严 重 。 那 么 怎么 才能 做 出 与 众 不 同 的 效果 呢 ? 答案 是 目 定义 View， 
也 可 以 叫 目 定 义 探 件 ， 通 过 目 定 义 View 我 们 可 以 实现 各 种 五 花 八 门 的 
效果 。 但 是 目 定义 View 是 有 一 定 难 度 的 ， 尤 其 是 复杂 的 目 定 义 View， 
大 部 分 时 候 我 们 仅仅 了 解 基本 控件 的 使 用 方法 是 无 法 做 出 复杂 的 上 自 定 
义 控件 的 。 为 了 更 好 地 自 定 义 View， 还 需要 掌握 View 的 的 层 工 作 原 
理 ， 比 如 View 的 测量 流程 、 布 局 流程 以 及 绘制 流程 ， 掌 握 这 几 个 基本 
流程 后 ， 我 们 就 对 View 的 讨 层 更 加 了 人 解 ， 这 样 我 们 就 可 以 做 出 一 个 比 
较 完善 的 目 定义 View。 


除了 View 的 三 大 流程 以 外 ，View 和 常见 的 回调 方法 也 是 需要 熟练 掌 
握 的 ， 比 如 构造 方法 、onAttach、onVisibilityChanged、onDetach 等 。 
另外 对 于 一 些 具 有 滑动 效果 的 目 定 义 View， 我 们 还 需要 处 理 View 的 请 
动 ， 如 有 果 遇 到 滑动 冲突 就 还 需要 解决 相应 的 滑动 冲突 ， 关 于 滑动 和 清 
动 冲 突 这 一 块 内 容 已 经 在 第 3 章 中 进行 了 全 面 介绍 。 目 定义 View 的 实 
现 看 起 来 很 复 洒 ， 实 际 上 说 简单 也 简单 。 总 结 来 说 ， 目 定义 View 是 有 
几 种 固定 类 型 的 ， 有 的 直接 继承 目 View 和 ViewGroup ， 而 有 的 则 选择 
继承 现 有 的 系统 控件 ， 这 些 都 可 以 ， 天 键 是 要 选择 最 适合 当前 需要 的 


方式 ， 选 对 目 定 义 View 的 实现 方式 可 以 起 到 事半功倍 的 效果 ， 下 面 加 
围绕 着 这 些 话题 一 一 展开 。 


4.1 初 识 ViewRoot 和 DecorView 


在 正式 介绍 View 的 三 大 流程 之 前 ， 我 们 必须 先 介 绍 一 些 基本 概 
念 ， 这 样 才 能 更 好 地 理解 View 的 measure、layout 和 draw 过 程 ， 本 廊 主 
要 介绍 ViewRoot 和 DecorView 的 概念 。 


ViewRoot 对 应 于 ViewRootImpl 类 ， 它 是 连接 WindowManager 和 
DecorView 的 纽 市 ，View 的 三 大 流程 均 是 通过 ViewRoot 来 完成 的 。 在 
ActivityThread 中 ， 当 Activity 对 象 被 创建 完毕 后 ， 会 将 DecorView 添 加 
到 Window 中 ， 同 时 会 创建 ViewRootImpl 对 象 ， 并 将 ViewRootImpl 对 象 
和 DecorView 建 立 天 联 ， 这 个 过 程 可 参看 如 下 源码 : 


root = new ViewRootImpl(view.getContext(),display); 


root.setView( view, wparams, panelParentView) ; 


View 的 绘制 流程 是 从 ViewRoot 的 performTraversals 方 法 开始 的 ， 它 
经 过 measure、layout 和 draw 三 个 过 程 才能 最 终 将 一 个 View 绘 制 出 来 ， 
H F measure H RM Æ View aM a, layout H RME View Et kR ae P 
的 放置 位 置 ， 而 draw 则 人 负责 将 View 绘 制 在 屏 间 上 。 和 针对 
performTraversals 的 大 致 流程 ， 可 用 流程 图 4-1 来 表示 。 


performMeasure measure onMeasure 国 .… measure 


| 


图 4-1 ”performTraversals 的 工作 流程 图 


如 图 4-1 所 示 ，performTraversals 会 依次 调用 performMeasure ` 
performLayout 和 performDraw 三 个 方法 ， 这 三 个 方法 分 别 完成 顶级 
View 的 measure、layout 和 draw 这 三 大 流程 ， 其 中 在 performMeasure 中 
会 调用 measure 方 法 ， 在 measure 方 法 中 又 会 调用 onMeasure 方 法 ， 在 
onMeasure 方 法 中 则 会 对 所 有 的 子 元 素 进 行 measure 过 程 ， 这 个 时 候 
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measure 过 程 。 接 着 子 元 素 会 重复 父 容器 的 measure 过 程 ， 如 此 反复 就 
完成 了 整个 View 树 的 所 历 。 同 理 ，performLayout 和 performDraw 的 传 
递 流程 和 performMeasure 是 类 似 的 ， 唯 一 不 同 的 是 ，performDraw 的 传 
遂 过 程 是 在 draw 方 法 中 通过 dispatchDraw 来 实现 的 ， 不 过 这 并 没有 本 
质 区 别 。 


measure 过 程 决 定 了 View 的 宽 / 高 ，Measure 完 成 以 后 ， 可 以 通过 
getMeasuredWidth 和 getMeasuredHeight 方 法 来 获取 到 View 测 量 后 的 宽 / 
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除外 ， 这 点 在 本 章 后 面 会 进行 说 明 。Layout 过 程 决定 了 View 的 四 个 项 
点 的 坐标 和 实际 的 View 的 宽 / 高 ， 完 成 以 后 ， 可 以 通过 getTop ` 
getBottom 、getLeft 和 getRight 来 拿 到 View 的 四 个 顶点 的 位 置 ， 并 可 以 
通过 getWidth 和 getHeight 方 法 来 拿 到 View 的 最 终 宽 /高 。Draw 过 程 则 决 
定 了 View 的 显示 ， 只 有 draw 方 法 完成 以 后 View 的 内 容 才 能 呈现 在 屏幕 
E 


如 图 4-2 所 示 ，DecorView 作 为 顶级 View， 一 般 情 况 下 它 内 部 会 包 
售 一 个 紧 直 方向 的 LinearLayout， 在 这 个 LinearLayout 里 面 有 上 下 两 个 
部 分 (具体 情况 和 Android 版 本 及 主题 有 关 ) ， 上 面 是 标题 栏 ， 下 面 是 
内 容 栏 。 在 Activity 中 我 们 通过 setContentView 所 设置 的 布局 文件 其 实 
瓯 是 被 加 到 内 容 栏 之 中 的 ， 而 内 容 栏 的 id 是 content， 因 此 可 以 理解 为 
Activity 指 定 布局 的 方法 不 叫 setview 而 叫 setContentView， 因 为 我 们 的 
布局 的 确 加 到 了 id 为 content 的 FrameLayout 中 。 如 何 得 到 content 呢 ? 可 
以 这 样 : ViewGroup content= findViewByld (R.android.id.content)。 如何 
得 到 我 们 设置 的 View 呢 ?可 以 这 样 : content.getChildAt(0)。 同 时 ， 通 
过 源码 我 们 可 以 知道 ，DecorView 其 实 是 一 个 FrameLayout，View 层 的 
事件 都 先 经 过 DecorView， 然 后 才 传 递 给 我 们 的 View。 


titlebar 


android.R.id.content 


图 4-2 ”顶级 View: DecorView 的 结构 


4.2 ”理解 MeasureSpec 


为 了 更 好 地 理解 View 的 测量 过 程 ， 我 们 还 需要 理解 MeasureSpec 。 
从 名 字 上 来 看 ，MeasureSpec 看 起 来 像 “ 测 量规 格 * 或 者 “测量 说 明 书 ”， 
不 管 怎么 翻译 ， 它 看 起 来 都 好 像 是 或 多 或 少 地 决定 了 View 的 测量 过 
程 。 通 过 源码 可 以 发 现 ，MeasureSpec 的 确 参与 了 View 的 measure 过 
fz co A n fe AE Al, ，MeasureSpec 是 干什么 的 呢 ? 确切 来 说 ， 
MeasureSpec 在 很 大 程度 上 决定 了 一 个 View 的 尺寸 规格 ， 之 所 以 说 是 很 
大 程度 上 是 因为 这 个 过 程 还 受 父 容器 的 影响 ， 因 为 父 容 器 影响 View 的 


MeasureSpec 的 创建 过 程 。 在 测量 过 程 中 ， 系 统 会 将 View 的 
LayoutParams 根 据 父 容器 所 施加 的 规则 转换 成 对 应 的 MeasureSpec， 然 
后 再 根据 这 个 measureSpec 来 测量 出 View 的 宽 / 高 。 上 面 提 到 过 ， 这 里 
的 宽 / 高 是 测量 宽 / 高 ， 不 一 定 等 于 View 的 最 终 宽 /高 。MeasureSpec 看 起 
来 有 点 复杂 ， 其 实 它 的 实现 是 很 简单 的 ， 下 面 会 详细 地 分 析 


MeasureSpec ° 


4.2.1 MeasureSpec 


MeasureSpec 代 表 一 个 32 位 int 值 ， 高 2 位 代表 SpecMode， 低 30 位 代 
表 SpecSize，SpecMode 是 指 测量 模式 ， 而 SpecSize 是 指 在 某 种 测量 模 
式 下 的 规格 大 小 。 下 面 先 看 一 下 MeasureSpec 内 部 的 一 些 常 量 的 定义 ， 
通过 下 面 的 代码 ， 应 该 不 难 理解 MeasureSpec 的 工作 原理 : 


private static final int MODE_SHIFT = 30; 
private static final int MODE_MASK = 0x3 << MODE_SHIFT; 
public static final int UNSPECIFIED = 0 << MODE_SHIFT; 
public static final int EXACTLY = 1 << MODE_SHIFT; 
public static final int AT_MOST = 2 << MODE_SHIFT; 
public static int makeMeasureSpec(int size,int mode) { 

if (sUseBrokenMakeMeasureSpec) { 

return size + mode; 
} else { 
return (size & ~MODE_MASK) | (mode & 


MODE_MASK) ; 
} 


} 

public static int getMode(int measureSpec) { 
return (measureSpec & MODE_MASK); 

} 

public static int getSize(int measureSpec) { 


return (measureSpec € ~MODE_MASK); 
} 


MeasureSpec 通 过 将 SpecMode 和 SpecSize 打 包 成 一 个 int 值 来 避免 过 
多 的 对 象 内 存 分 配 ， 为 了 方便 操作 ， 其 提供 了 打包 和 解 包 方法 。 
SpecMode 和 SpecSize 也 是 一 个 int 值 ， 一 组 SpecMode 和 SpecSize 可 以 打 
包 为 一 个 MeasureSpec， 而 一 个 MeasureSpec 可 以 通过 解 包 的 形式 来 得 
出 其 原始 的 SpecMode 和 SpecSize ， 需 要 注意 的 是 这 里 提 到 的 
MeasureSpec 是 指 MeasureSpec 所 代表 的 int 值 ， 而 并 非 MeasureSpec 本 
身 o 


SpecMode 有 三 类 ， 每 一 类 都 表示 特殊 的 含义 ， 如 下 所 示 。 


UNSPECIFIED 


父 容 需 不 对 View 有 任何 限制 ， 要 多 大 给 多 大 ， 这 种 情况 一 般 用 于 
系统 内 部 ， 表 示 一 种 测量 的 状态 。 


EXACTLY 


父 容器 已 经 检测 出 View 所 需要 的 精确 大 小 ， 这 个 时 候 View 的 最 终 
大 小 就 是 SpecSize 所 指定 的 值 。 它 对 应 于 LayoutParams 中 的 
match_parent 和 具体 的 数值 这 两 种 模式 。 


AT_MOST 


父 容器 指定 了 一 个 可 用 大 小 即 SpecSize，View 的 大 小 不 能 大 于 这 
个 值 ， 有 具体 是 什么 值 要 看 不 同 View 的 具体 实现 。 它 对 应 于 


LayoutParams 中 的 wrap_content ° 


4.2.2 “MeasureSpec 和 LayoutParams 
的 对 应 关系 


上 面 提 到 ， 系 统 内 部 是 通过 MeasureSpec 来 进行 View 的 测量 ， 但 是 
正常 情况 下 我 们 使 用 View 指 定 MeasureSpec， 尽 管 如 此 ， 但 是 我 们 可 以 
给 View ix 置 LayoutParams > E View 测量 的 时 候 ， 系 统 会 将 
LayoutParams 在 父 容 怖 的 约束 下 转换 成 对 应 的 MeasureSpec， 然 后 再 根 
据 这 个 MeasureSpec 来 确定 View 测 量 后 的 宽 / 高 。 需 要 注意 的 是 ， 
MeasureSpec 不 是 唯一 由 LayoutParams 决 定 的 ，LayoutParams 和 需要 和 父 
容 絮 一 起 才能 决定 View 的 MeasureSpec， 从 而 进一步 决定 View 的 贺 / 
高 。 男 外 ， 对 于 顶级 View ( 即 DecorView) 和 普通 View 来 说 ， 
MeasureSpec 的 转换 过 程 略 有 不 同 。 对 于 DecorView， 其 MeasureSpec 由 
窗口 的 尺寸 和 其 上 自身 的 LayoutParams 来 共同 确定 ; 对 于 普通 View， 其 
MeasureSpec 由 父 容 器 的 MeasureSpec 和 目 身 的 LayoutParams 来 共同 决 
定 ，MeasureSpec 一 旦 确定 后 ，onMeasure 中 就 可 以 确定 View 的 测量 视 / 


=] 
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对 于 DecorView 来 说 ， 在 ViewRootImpl 中 的 measureHierarchy 方 法 
中 有 如 下 一 段 代 码 ， 它 展示 了 DecorView 的 MeasureSpec 的 创建 过 程 ， 
其 中 desiredWindowWidth 和 desired-WindowHeight 是 屏幕 的 尺寸 : 


接着 再 看 一 下 getRootMeasureSpec 方 法 的 实现 : 


// Window wants to be an exact size. Force root 
view to be that size. 
measureSpec = 
MeasureSpec.makeMeasureSpec(rootDimension, Measure- 
Spec.EXACTLY); 
break; 


} 


return measureSpec; 


通过 上 述 代 码 ，DecorView 的 MeasureSpec 的 产生 过 程 就 很 明确 
了 ， 具 体 来 说 其 遵守 如 下 规则 ， 根 据 它 的 LayoutParams 中 的 宽 / 高 的 参 
数 来 划分 


e LayoutParams.MATCH_PARENT: 精确 模式 ， 大 小 就 是 窗口 的 大 
a 

。 LayoutParams.WRAP_CONTENT: 最 大 模式 ， 大 小 不 定 ， 但 是 不 
能 超过 窗口 的 大 小 ; 

。 国定 大 小 (比如 100dp) : 精确 模式 ， 大 小 为 LayoutParams 中 指定 
的 大 小 。 


对 于 普通 View 来 说 ， 这 里 是 指 我 们 布局 中 的 View ，View 的 
measure 过 程 由 ViewGroup 传递 而 来 ， 先 看 一 下 ViewGroup 的 
measureChildWithMargins 方 法 : 


protected void measureChildwithMargins(View child, 
int parentWidthMeasureSpec, int widthUsed, 


int parentHeightMeasureSpec, int heightUsed) { 


final MarginLayoutParams lp = (MarginLayoutParams ) 
child.getLayout-Params(); 


final int childwidthMeasureSpec = 


+ 


getChildMeasureSpec(parentWidthMeasureSpec, mPaddingLeft 
mPaddingRight + 1p.leftMargin + 1p.rightMargin 
+ widthUsed, 1p.width); 
final int childHeightMeasureSpec = 
getChildMeasureSpec(parentHeight -MeasureSpec, mPaddingTop 十 


mPaddingBottom + 1p.topMargin + 1p.bottomMargin 


heightUsed, 1p.height); 


child.measure(childWidthMeasureSpec, childHeightMeasureSpec); 


} 


上 壕 方 法 会 对 了 于 元 素 进 行 measure， 在 调用 子 元 素 的 measure 方 法 
之 前 会 先 通过 getChildMeasureSpec 方 法 来 得 到 子 元 素 的 MeasureSpec。 
从 代码 来 看 ， 很 显然 ， 子 元 素 的 MeasureSpec 的 创建 与 父 容器 的 
MeasureSpec 和子 元 素 本 里 的 LayoutParams 有 关 ， 此 外 还 和 View 的 
margin 及 padding 有 有关， 具体 情况 可 以 看 一 下 ViewGroup 的 
getChildMeasureSpec 方 法 ， 如 下 所 示 。 


public static int getChildMeasureSpec(int spec,int 
padding, int child-Dimension) { 

int specMode = MeasureSpec.getMode(spec); 

int specSize = MeasureSpec.getSize(spec); 


int size = Math.max(0,specSize -padding); 
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父 容 器 的 尺寸 减 去 padding， 有 具体 代码 如 下 所 示 。 


int specSize = MeasureSpec.getSize(spec); 


int size = Math.max(0,specSize -padding); 


getChildMeasureSpec 清 楚 展示 了 普通 View 的 MeasureSpec 的 创建 规 
则 ， 为 了 更 清晰 地 理解 getChildMeasureSpec 的 逻辑 ， 这 里 提供 一 个 
表 ， 表 中 对 getChildMeasureSpec 的 工作 原理 进行 了 梳理 ， 请 看 表 4-1。 
注意 ， 表 中 的 parentSize 是 指 父 容 器 中 目前 可 使 用 的 大 小 。 


表 4-1 普通 View 的 MeasureSpec 的 创建 规则 


parentSpecMode 
EXACTLY AT_ MOST UNSPECIFIED 


EXACTLY EXACTLY EXACTLY 


dp/px Aa alas AMÉ 
childSize childSize childSize 


EXACTLY AT_MOST UNSPECIFIED 
match parent ) . 
parentSize parentSize 0 


AT_MOST AT_MOST UNSPECIFIED 


warap_content 


parentSize parentSize 0 


针对 表 4-1， 这 里 再 做 一 下 说 明 。 前 面 已 经 提 到 ， 对 于 普通 View， 
其 MeasureSpec 由 父 容 堪 的 MeasureSpec 和 目 身 的 LayoutParams 来 共同 
决定 ， 那 么 针对 不 同 的 父 容器 和 View 本 身 不 同 的 LayoutParams，View 
束 可 以 有 和 多 种 MeasureSpec。 这 里 人 简单 说 一 下 ， 当 View 采 用 固定 沉 / 高 
的 上 时候， 不 管 父 容 絮 的 MeasureSpec 是 什么 ，View 的 MeasureSpec 都 是 
精确 模式 并 且 其 大 小 遵循 Layoutparams 中 的 大 小 。 当 View 的 宽 / 高 是 
match_parent 时 ， 如 果 父 容 句 的 模式 是 精准 模式 ， 那 么 View 也 是 精准 
模式 并 有 旦 其 大 小 是 父 容器 的 和 独 余 空间 ; 如 果 父 容 右 是 最 大 模式 ， 那 么 
View 也 是 最 大 模式 并 且 其 大 小 不 会 超过 父 容 顺 的 剩余 空间 。 当 View 的 
宽 / 高 是 wrap_content 时 ， 不 管 父 容 器 的 模式 是 精准 还 是 最 大 化 ，View 
的 模式 总 是 最 大 化 并 且 大 小 不 能 超过 父 容 器 的 剩余 空间 。 可 能 读者 会 
发 现 ， 在 我 们 的 分 析 中 漏 掉 了 UNSPECIFIED 模 式 ， 那 是 因为 这 个 模式 


主要 用 于 系统 内 部 多 次 Measure 的 情形 ， 一 般 来 说 ， 我 们 不 需要 关注 此 
模式 。 


通过 表 4-1 可 以 看 出 ， 只 要 提供 父 容 絮 的 MeasureSpec 和 子 元 素 的 
LayoutParams ， 束 可 以 快速 地 确定 出 子 元 素 的 MeasureSpec 了 了， 有 了 
MeasureSpec 束 可 以 进一步 确定 出 子 元 到 测量 后 的 大 小 了 。 需 要 说 明 的 
是 ， 表 4-1 并 非 是 什么 经 验 总 结 ， 它 只 是 getChildMeasureSpec 这 个 方法 
以 表格 的 方式 呈现 出 来 而 已 。 


43 ”View 的 工作 流程 


View 的 工作 流程 主要 是 指 measure、layout、draw 这 三 大 流程 ， 即 
测量 、 布 局 和 绘制 ， 其 中 measure 确 定 View 的 测量 宽 / 高 ，layout 确 定 
View 的 最 终 宽 /高 和 四 个 顶点 的 位 置 ， 而 draw 则 将 View 绘 制 到 屏幕 上 。 


4.3.1 measure 过 程 


measure 过 程 要 分 情况 来 看 ， 如 果 只 是 一 个 原始 的 View， 那 么 通过 
measure 方 法 就 完成 了 其 测量 过 程 ， 如 果 是 一 个 ViewGroup， 除 了 完成 
自己 的 测量 过 程 外 ， 还 会 遇 历 去 调用 所 有 子 元 素 的 measure 方 法 ， 各 个 
子 元 素 再 递归 去 执行 这 个 流程 ， 下 面 针 对 这 两 种 情况 分 别 讨 论 。 


1. View 的 measure 过 程 


View 的 measure 过 程 由 其 measure 方 法 来 完成 ，measure 方 法 是 一 个 
final 类 型 的 方法 ， 这 意味 着 子 类 不 能 重 写 此 方法 ， 在 View 的 measure 方 


法 中 会 去 调用 View 的 onMeasure 方 法 ， 因 此 只 需要 看 onMeasure 的 实现 
即 可 ，View 的 onMeasure 方 法 如 下 所 示 。 


protected void onMeasure(int widthMeasureSpec, int 


heightMeasureSpec) { 


setMeasuredDimension(getDefaultSize(getSuggestedMinimumwidth(), 
widthMeasureSpec), getDefaultSize(getSuggestedMinimumHeight(), he 


ightMeasureSpec)); 
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方法 会 设置 View 视 /高 的 测量 值 ， 因 此 我 们 只 需要 看 getDefaultSize 这 个 
方法 即 可 : 


public static int getDefaultSize(int size,int measureSpec) 


int result = size; 
int specMode = MeasureSpec.getMode(measureSpec) ; 
int specSize = MeasureSpec.getSize(measureSpec); 
switch (specMode) { 
case MeasureSpec.UNSPECIFIED: 
result = size; 
break; 
case MeasureSpec.AT_MOST: 
case MeasureSpec.EXACTLY: 
result = specSize; 


break; 


A 


return result; 


} 


可 以 看 出 ，getDefaultSize 这 个 方法 的 逻辑 很 简单 ， 对 于 我 们 来 
说 ， 我 们 只 需要 看 AT_MOST 和 .EXACTLY 这 两 种 情况 。 简 单 地 理解 ， 
其 实 getDefaultSize 返 回 的 大 小 就 是 measureSpec 中 的 specSize， 而 这 个 
specSize 束 是 View 测 量 后 的 大 小 ， 这 里 多 次 提 到 测量 后 的 大 小 ， 是 因 
为 View 最 终 的 大 小 是 在 layout 阶 段 确定 的 ， 所 以 这 里 必须 要 加 以 区 
Sy, 但 是 几乎 所 有 情况 下 View 的 测量 大 小 和 最 终 大 小 是 相等 的 。 


至 于 UNSPECIFIED 这 种 情况 ， 一 般 用 于 系统 内 部 的 测量 过 程 ， 在 
这 种 情况 下 ，View 的 大 小 为 getDefaultSize 的 第 一 个 参数 size， 即 宽 / 高 
7} Fill X getSuggestedMinimum Width F} getSuggestedMinimumHeight ix P 
个 方法 的 返回 值 ， 看 一 下 它们 的 源码 : 


protected int getSuggestedMinimumwidth() { 
return (mBackground == null) ? mMinWidth 
max(mMinwWidth,mBackground.getMinimumwWidth()); 
J 
protected int getSuggestedMinimumHeight() { 
return (mBackground == null) ? mMinHeight 


max(mMinHeight,mBackground.getMinimumHeight()); 


} 


这 里 A 分 析 getSuggestedMinimumWidh 方法 的 实现 ， 
getSuggestedMinimumHeight 和 它 的 实现 原理 是 一 样 的 。 从 
getSuggestedMinimumWidth 的 代码 可 以 看 出 ， 如 采 View 没 有 设置 育 


景 ， 那 么 View 的 宽度 为 mmMinwidth , fi mMinWidth 对 应 于 
android:minWidth 这 个 属性 所 指 ue E, 因此 View 的 宽度 即 为 
android:minWidth 属性 所 指定 的 值 。 这 个 属性 如 果 不 指 定 ， 那 么 
mMinWidth 则 默认 为 0;， 如 果 View 指 定 了 背景 ， 则 View 的 宽度 为 
max(mMinWidth,mBackground.getMinimumWidth()) ° mMinWidth 的 & 
义 我 们 已 经 知道 了 ， 那 么 mBackground.getMinimumWidth() 是 什么 呢 ? 
我 们 看 一 下 Drawable 的 getMinimumWidth 方 法 ， 如 下 所 示 。 


public int getMinimumWidth() { 
final int intrinsicWidth = getIntrinsicwidth(); 
return intrinsicWidth > 0 ? intrinsicWidth : 0; 


} 


ALLA tt, getMinimumWidth3X E] HY Wi x Drawable by JR 48 Ta JE , 
Au en l 始 宽度 ， 否 则 就 返回 0。 那 么 Drawable 在 什么 
情况 下 有 原始 视 度 呢 ? 这 里 先 举 个 例 T ，ShapeDrawable 无 原 
始 宽 / 高 ， 而 BitmapDrawable 有 原始 宽 / 高 《图片 的 尺寸 ) ， 详 细 内 容 会 
在 第 6 章 进 行 介绍 。 


里 再 总 结 一 下 getSuggestedMinimumWidth 的 逻辑 : a 
A cs 那么 返回 android:minWidth 这 个 属性 所 指定 的 值 ， 这 个 值 
可 以 为 0， 如 果 View 设 置 了 背景 ， nn 
小 宽度 这 两 者 中 的 最 大 值 ， getSuggestedMinimumWidth 和 
getSuggestedMinimumHeight Hy 3& E] E Wi xe View TE UNSPECIFIED IF ÖL 
FAME TEA > 


从 getDefaultSize 方 法 的 实现 来 看 ，View 的 宽 / 高 由 specSize 决 定 ， 
所 以 我 们 可 以 得 出 如 下 结论 : 直接 继承 View 的 目 定义 控件 需要 重 写 


onMeasure 方 法 并 设置 wrap_content 时 的 目 身 大 小 ， 否 则 在 布局 中 使 用 
wrap_content 就 相当 于 使 用 match_parent。 为 什么 呢 ? 这 个 原因 需要 结 
合 上 述 代 码 和 表 4-1 才 能 更 好 地 理解 。 从 上 述 代 码 中 我 们 知道 ， 如 采 
View 在 布局 中 使 用 wrap_content， 那 么 它 的 specMode 是 AT_MOST 模 
式 ， 在 这 种 模式 下 ， 它 的 视 / 高 等 于 specSize; 查 表 4-1 可 知 ， 这 种 情况 
下 View 的 specSize 是 parentSize， 而 parentSize 是 父 容 絮 中 目前 可 以 使 用 
的 大 小 ， 也 残 是 父 容 右 当前 剩余 的 空间 大 小 。 很 显然 ，View 的 宽 / 高 束 
等 于 父 容 器 当前 剩余 的 空间 大 小 ， 这 种 效果 和 在 布局 中 使 用 
match_parent 完 全 一 致 。 如 何 解 决 这 个 问题 呢 ? 也 很 简单 ， 代 码 如 下 所 
示 。 


protected void onMeasure(int widthMeasureSpec, int 
heightMeasureSpec) { 
super .onMeasure(widthMeasureSpec, heightMeasureSpec); 
int widthSpecMode = 
MeasureSpec.getMode(widthMeasureSpec ) ; 
int widthSpecSize = 
MeasureSpec.getSize(widthMeasureSpec ) ; 
int heightSpecMode = 
MeasureSpec.getMode(heightMeasureSpec); 
int heightSpecSize = 
MeasureSpec.getSize(heightMeasureSpec); 
if (widthSpecMode == MeasureSpec.AT_MOST && 
heightSpecMode == 
MeasureSpec.AT_MOST) { 
setMeasuredDimension(mWidth,mHeight ) ; 


} else if (widthSpecMode == MeasureSpec.AT_MOST) { 


setMeasuredDimension(mWidth, heightSpecSize) ; 
} else if (heightSpecMode == MeasureSpec.AT_MOST) { 


setMeasuredDimension(widthSpecSize, mHeight ) ; 


} 


在 上 面 的 代码 中 ， 我 们 只 需要 给 View 指 定 一 个 默认 的 内 部 宽 / 高 
(mWidth 和 mHeight) ， 并 在 wrap_content 时 设置 此 宽 / 高 即 可 。 对 于 非 
wrap_content 情 形 ， 我 们 沿用 系统 的 测量 值 即 可 ， 人 至 于 这 个 默认 的 内 部 
宽 / 高 的 大 小 如 何 指定 ， 这 个 没有 固定 的 依据 ， 根 据 需要 灵活 指定 即 
可 。 如 果 查 看 TextView、ImageView 等 的 源码 就 可 以 知道 ， 针 对 
wrap_content 情 形 ， 它 们 的 onMeasure 方 法 均 做 了 特殊 处 理 ， 读 者 可 以 
目 行 查看 它们 的 源码 。 


2. ViewGroup 的 measure 过 程 


对 于 ViewGroup 来 说 ， 除 了 完成 目 己 的 measure 过 程 以 外 ， 还 会 遇 
历 去 调用 所 有 子 元 素 的 measure 方 法 ， 各 个 子 元 素 再 递归 去 执行 这 个 过 
程 。 和 View 不 同 的 是 ，ViewGroup 是 一 个 抽象 类 ， 因 此 它 没 有 重 写 
View 的 onMeasure 方 法 ， 但 是 它 提 供 了 一 个 叫 measureChildren 的 方法 ， 
如 下 押宝 


protected void measureChildren(int widthMeasureSpec, int 
heightMeasureSpec) { 
final int size = mChildrenCount; 
final View[] children = mChildren; 
Tor CINE ES O ee Gi Ze mal) a 


final View child = children[i]; 


if ((child.mViewFlags & VISIBILITY_MASK) != 
GONE) { 


measureChild(child, widthMeasureSpec, heightMeasureSpec); 


A 


从 上 述 代 码 来 看 ，ViewGroup 在 measure 时 ， 会 对 每 一 个 子 元 素 进 
行 measure，measureChild 这 个 方法 的 实现 也 很 好 理解 ， 如 下 所 示 。 


protected void measureChild (View child, int 
parentwidthMeasureSpec, 
int parentHeightMeasureSpec) { 
final LayoutParams lp = child.getLayoutParams(); 

final int childwidthMeasureSpec = 
getChildMeasureSpec(parentWidth-MeasureSpec, 

mPaddingLeft + mPaddingRight, Ip.width); 

final int childHeightMeasureSpec = 
getChildMeasureSpec(parentHeight -MeasureSpec, 

mPaddingTop + 


mPaddingBottom, 1p.height); 


child.measure(childWidthMeasureSpec, childHeightMeasureSpec); 


} 


很 显然 ，measureChild 的 思想 就 是 取出 子 元 素 的 LayoutParams， 然 
后 再 通过 getChildMeasureSpec 来 创建 子 元 丸 的 MeasureSpec， 接 着 将 


MeasureSpec 直接 传递 给 View AY measure 方 法 来 进行 测量 。 
getChildMeasureSpec 的 工作 过 程 已 经 在 上 面 进 行 了 详细 分 析 ， 通 过 表 
4-1 可 以 更 清楚 地 了 解 它 的 逻辑 。 


我 们 知道 ，ViewGroup 并 没有 定义 其 测量 的 具体 过 程 ， 这 是 因为 
ViewGroup 是 一 个 抽象 类 ， 其 测量 过 程 的 onMeasure 方 法 需要 各 个 子 类 
去 具体 实现 ， 比 如 LinearLayout、RelativeLayout 等 ， 为 什么 ViewGroup 
不 像 View 一 样 对 其 onMeasure 方 法 做 统一 的 实现 呢 ? 那 是 因为 不 同 的 
ViewGroup 子 类 有 不 同 的 布局 特性 ， 这 导致 它们 的 测量 细节 各 不 相 
同 ， 比 如 LinearLayout 和 RelativeLayout 这 两 者 的 布局 特性 显然 不 同 ， 
此 ViewGroup 无 法 做 统一 实现 。 下 面 就 通过 LinearLayonut 的 
onMeasure 方 法 来 分 析 ViewGroup 的 measure 过 程 ， 其 他 Layout 类 型 读者 
可 以 自行 分 析 。 


首先 来 看 LinearLayout 的 onMeasure 方 法 ， 如 下 所 示 。 


protected void onMeasure(int widthMeasureSpec, int 
heightMeasureSpec) { 


if (mOrientation == VERTICAL) { 


measureVertical(widthMeasureSpec, heightMeasureSpec ) ; 


) else { 


measureHorizontal(widthMeasureSpec, heightMeasureSpec ) ; 


A 


上 述 代码 很 答 单 ， 我 们 选择 一 个 来 看 一 下 ， 比 如 选择 得 看 坚 直 布 
局 的 LinearLayout 的 测量 过 程 ， 即 measureVertical 方 法 ，measureVertical 
的 源码 比较 长 ， 下 面 只 描述 其 大 概 逻 辑 ， 首 先 看 一 段 代 码 : 


1p.bottomMargin + 
getNextLocationOffset(child)); 
} 


从 上 面 这 段 代 码 可 以 看 出 ， 系 统 会 瑶 历 子 元 素 并 对 每 个 子 元 素 执 
行 measureChild-BeforeLayout 方 法 ， 这 个 方法 内 部 会 调用 子 元 素 的 
measure 方 法 ， 这 样 各 个 子 元 素 束 开始 依次 进入 measure 过 程 ， 并 且 系 
统 会 通过 mTotalLength 这 个 变量 来 存储 LinearLayout 在 竖 直 方 同 的 初步 
高 度 。 每 测量 一 个 子 元 素 ，mTotalLength 就 会 增加 ， 增 加 的 部 分 主要 
包括 了 子 元 素 的 高 度 以 及 子 元 素 在 坚 直 方 同 上 的 margin 等 。 STIA 
测量 完毕 后 ，LinearLayout 会 测量 目 己 的 大 小 ， 源 码 如 下 所 示 。 


// Add in our padding 
mTotalLength += mPaddingTop + mPaddingBottom; 
int heightSize = mTotalLength; 
// Check against our minimum height 
heightSize = 
Math.max(heightSize, getSuggestedMinimumHeight()); 
// Reconcile our calculated size with the heightMeasureSpec 
int 
heightSizeAndState=resolveSizeAndState(heightSize, heightMeasure 
Spec, 
0); 
heightSize = heightSizeAndState € MEASURED_SIZE_MASK; 


setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureS 


pec, 
childState), 
heightSizeAndState) ; 


这 里 对 上 述 代 码 进 行 说 明 ， 当 子 元 素 测 量 完 毕 后 ，LinearLayout 会 
根据 子 元 素 的 情况 米 测 量 自 己 的 大 小 。 针 对 竖 直 的 LinearLayout 而 言 ， 
它 在 水 平方 同 的 测量 过 程 遵 循 View 的 测量 过 程 ， 在 竖 直 方 同 的 测量 过 
程 则 和 View 有 所 不 同 。 具 体 米 说 是 指 ， 如 有 果 它 的 布局 中 高 度 采用 的 是 
match_parent 或 者 具体 数值 ， 那 么 它 的 测量 过 程 和 View 一 致 ， 即 高 度 
为 specSize; 如 果 它 的 布局 中 高 度 采用 的 是 wrap_content， 那 么 它 的 高 
度 是 所 有 子 元 素 所 占用 的 高 度 总 和 ， 但 是 仍然 不 能 超过 它 的 父 容 恬 的 
剩余 空间 ， 当 然 它 的 最 终 高 度 还 需要 考虑 其 在 坚 直 方 各 的 padding， 这 
个 过 程 可 以 进一步 参看 如 下 源码 : 


public static int resolveSizeAndState(int size,int 
measureSpec, int 
childMeasuredState) { 
int result = size; 
int specMode = MeasureSpec.getMode(measureSpec) ; 
int specSize = MeasureSpec.getSize(measureSpec); 
switch (specMode) { 
case MeasureSpec.UNSPECIFIED: 
result = size; 
break; 
case MeasureSpec.AT_MOST: 
if (specSize < size) { 


result = specSize | 


MEASURED_STATE_TOO_SMALL; 
} else { 
result = size; 
} 
break; 
case MeasureSpec.EXACTLY: 
result = specSize; 


break; 


return result 
(childMeasuredState&MEASURED_STATE_MASK) ; 
} 


View 的 measure 过 程 是 三 大 流程 中 最 复杂 的 一 个 ，measure 完 成 以 
后 ， 通 过 getMeasured-Width/Height 方 法 就 可 以 正确 地 获取 到 View 的 测 
量 宽 / 高 。 需 要 注意 的 是 ， 在 某 些 极端 情况 下 ， 系 统 可 能 需要 多 次 
measure 才 能 确定 最 终 的 测量 宽 / 高 ， 在 这 种 情形 下 ， 在 onMeasure 方 法 
中 拿 到 的 测量 宽 / 高 很 可 能 是 不 准确 的 。 一 个 比较 好 的 习惯 是 在 
onLayout 方 法 中 去 获取 View 的 测量 宽 / 高 或 者 最 终 宽 /高 。 


上 面 已 经 对 View 的 measure 过 程 进行 了 详细 的 分 析 ， 现 在 考虑 一 种 
情况 ， 比 如 我 们 想 在 Activity 已 启动 的 时 候 束 做 一 件 任务 ,但 是 这 一 件 
任务 需要 获取 某 个 View 的 视 / 高 。 读 者 可 能 会 说 ， 这 很 简单 啊 ， 在 
onCreate 或 者 onResume 里 面 去 获取 这 个 View 的 宽 / 高 不 束 行 了 ? 读者 可 
以 上 自行 试 一 下 ， 实 际 上 在 onCreate、onStart、onResume 中 均 无 法 正确 
得 到 某 个 View 的 宽 / 高 信息 ， 这 是 因为 View 的 measure 过 程 和 Activity 的 
生命 周期 方法 不 是 同步 执行 的 ， 因 此 无 法 保证 Activity 执 行 了 


onCreate、onStart、onResume 时 革 个 View 已 经 测量 完毕 了 ， 如 果 View 
还 没有 测量 完毕 ， 那 么 获得 的 宽 / 高 区 是 0。 有 没有 什么 方法 能 解决 这 
个 问题 呢 ? 答案 是 有 的 ， 这 里 给 出 四 种 方法 来 解决 这 个 问题 


(1) Activity/View#onWindowFocusChanged ° 


onWindowFocusChanged 这 个 方法 的 含义 是 View 已 经 初始 化 完毕 
了 ， 宽 /高 已 经 准备 好 了 ， 这 个 时 候 去 获取 筑 / 高 是 没 问题 的 。 需 要 注 
意 的 是 ，onWindowFocusChanged 会 被 调用 多 次 ， 当 Activity 的 窗口 得 
到 焦点 和 失去 焦点 时 均 会 被 调用 一 次 。 具 体 来 说 ， 当 Activity 继 续 执 行 
和 和 暂停 执行 时 ，onWindowFocusChanged 均 会 被 调用 ， 如 果 频 党 地 进行 
onResume Fl onPause, 35 ~ onWindowFocusChanged E E 31 2 Hh Val 
用 。 上 典型 代码 如 下 : 


public void onwindowFocusChanged(boolean hasFocus) { 
super .onWindowFocusChanged(hasFocus) ; 
if (hasFocus) { 
int width = view.getMeasuredwWidth(); 


int height = view.getMeasuredHeight(); 


(2) view.post(runnable) ° 


iw postal LAR — runnable EEE BU GIN Bab, Al Se 
Looper 调 用 此 runnable 的 时 候 ，View 也 已 经 初始 化 好 了 。 暴 型 代码 如 
下 : 


(3) ViewTreeObserver ° 


使 用 ViewTreeObserver 的 众多 回调 可 以 完成 这 个 功能 ， 比 如 使 用 
OnGlobalLayoutListener 这 个 接口 ， 当 View 树 的 状态 发 生 改 变 或 者 View 
树 内 部 的 View 的 可 见 性 发 现 改 变 时 ，onGlobalLayout 方 法 将 被 回调 ， 
此 这 是 获取 View 的 宽 / 高 一 个 很 好 的 时 机 。 需 要 注意 的 是 ， 伴 随 着 
View 树 的 状态 改变 等 ，onGlobalLayout 会 被 调用 多 次 。 典 型 代码 如 
Is 


view.getViewTreeObserver().removeGlobalOnLayoutListener(this); 
int width = view.getMeasuredwWidth(); 


int height = view.getMeasuredHeight(); 


(4) view.measure(int widthMeasureSpec,int heightMeasureSpec) 


手动 对 View 进 行 measure 来 得 到 View 的 宽 / 高 。 这 种 方法 比较 


通过 
这 里 要 分 情况 处 理 ， 根 据 View 的 LayoutParams 来 分 


AS Ju 
复杂 ， 


match_parent 
直接 放弃 ， 无 法 measure 出 具体 的 宽 / 高 。 原 因 很 简单 ， 根 据 View 
需 道 


HJ measure dE, ， 如 表 4-1 所 示 ， 构 造 此 种 MeasureSpec 需 要 知 
空间 ， 而 这 个 时 候 我 们 无 法 知道 parentSize 


Eb 测 量 出 View 的 大 小 。 


parentSize， 即 父 容器 的 剩余 
的 大 小 ， 所 以 理论 上 不 可 能 


具体 的 数值 (dp/px) 


比如 宽 / 高 都 是 100pX， 如 下 measure: 
int widthMeasureSpec 
MeasureSpec.makeMeasureSpec(100,MeasureSpec 


EXACTLY); 
int heightMeasureSpec 


MeasureSpec.makeMeasureSpec(100, MeasureSpec 


EXACTLY); 


view.measure(widthMeasureSpec, heightMeasureSpec); 


wrap_content 


如 下 measure: 


int widthMeasureSpec = MeasureSpec.makeMeasureSpec( (1 << 
30) -1, 
MeasureSpec.AT_MOST); 
int heightMeasureSpec = MeasureSpec.makeMeasureSpec( (1 << 
30) -1, 
MeasureSpec.AT_MOST); 


view.measure(widthMeasureSpec, heightMeasureSpec); 


主意 到 (1 << 30)-1， 通 过 分 析 MeasureSpec 的 实现 可 以 知道 ，View 
人 
也 就 是 (1 << 30) - 1， 在 最 大 化 模式 下 ， 我 们 用 View 理 论 上 能 文 持 的 最 
大 值 去 构造 MeasureSpec 是 合理 的 。 


关于 View 的 measure， 网 络 上 有 两 个 错误 的 用 法 。 为 什么 说 是 错误 
的 ， 首 先 其 违背 了 系统 的 内 部 实现 规范 (因为 无 法 通过 错误 的 
MeasureSpec 去 得 出 合法 的 SpecMode， 从 而 导致 measure 过 程 出 错 ) ， 
其 次 不 能 你 证 一 定 能 measure 出 正确 的 结 


第 一 种 错误 用 法 : 


int widthMeasureSpec 


MeasureSpec.makeMeasureSpec(-1,MeasureSpec. 


UNSPECIFIED); 
int heightMeasureSpec = 
MeasureSpec.makeMeasureSpec(-1,MeasureSpec. 
UNSPECIFIED); 


view.measure(widthMeasureSpec, heightMeasureSpec); 


第 二 种 错误 用 法 : 


view.measure(LayoutParams.WRAP_CONTENT, LayoutParams .WRAP_CONTEN 


T) 


4.3.2 layout 过 程 


Layout 的 作用 是 ViewGroup 用 来 确定 子 元 素 的 位 置 ， 当 ViewGroup 
的 位 置 补 确定 后 ， 它 在 onLayout 中 会 涡 历 所 有 的 子 元 素 并 调用 其 layout 
方法 ， 在 layout 方 法 中 onLayout 方 法 义 会 被 调用 。Layout 过 程 和 measure 
过 程 相 比 就 简单 多 了 ，layout 方 法 确定 View 本 身 的 位 置 ， 而 onLayout 方 
法 则 会 确定 所 有 子 元 素 的 位 置 ， 先 看 View 的 layout 方 法 ， 如 下 所 示 。 


public void layout(int 1,int t,int r, int b) { 
if ((mPrivateFlags3 8 
PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT) != 0) { 


onMeasure(mOldwidthMeasureSpec, mOldHeightMeasureSpec ) ; 
mPrivateFlags3 &= 
~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT; 


t 
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT; 


mPrivateFlags3 |= PFLAG3_IS_LAID_OUT; 


} 


layonut 方 法 的 大 致 流程 如 下 : 首先 会 通过 setFrame 方 法 来 设 定 View 
的 四 个 顶点 的 位 置 ， 即 初始 化 mLeft、mRight、mTop 和 mBottom 这 四 
个 值 ，View 的 四 个 顶点 一 旦 确定 ， 那 么 View 在 父 容 强 中 的 位 置 也 就 确 
ES; 接着 会 调用 onLayout 方 法 ， 这 个 方法 的 用 途 是 父 容 絮 人 确定 子 元 
素 的 位 置 ， 和 onMeasure 方 法 类 似 ，onLayout 的 具体 实现 同样 和 具体 的 
布局 有 关 ， 所 以 View 和 ViewGroup 均 没有 真正 实现 onLayout 方 法 。 接 
下 来 ， 我 们 可 以 看 一 下 LinearLayout 的 onLayout 方 法 ， 如 下 所 示 。 


protected void onLayout(boolean changed,int 1,int t,int 
r,int b) { 
if (mOrientation == VERTICAL) { 
layoutVertical(1,t,r,b); 
} else { 
layoutHorizontal(1,t,r,b); 


i 


LinearLayout 中 onLayout 的 实现 逻辑 和 onMeasure 的 实现 逻辑 类 
似 ， 这 里 选择 layoutVertical 继 续 讲解 ， 为 了 更 好 地 理解 其 逻辑 ， 这 里 
只 给 出 了 主要 的 代码 : 


这 里 分 析 一 下 layoutVertical 的 代码 逻辑 ， 可 以 看 到 ， 此 方法 会 通 
历 所 有 子 元 素 并 调用 setChildFrame 方 法 来 为 子 元 素 指 定 对 应 的 位 置 ， 
其 中 childTop 会 逐渐 增 大 ， 这 就 意味 着 后 面 的 子 元 素 会 被 放 置 在 徘 下 
的 位 置 ， 这 刚好 符合 竖 直 方 同 的 LinearLayout 的 特性 。 至 于 
setChildFrame， 它 仪 仅 是 调用 子 元 素 的 layout 方 法 而 已 ， 这 样 父 元 素 在 
layout 方 法 中 完成 自己 的 定位 以 后 ， 就 通过 onLayout 方 法 去 调用 子 元 素 
的 layout 方 法 ， 子 元 素 又 会 通过 自己 的 layout 方 法 来 确定 自己 的 位 置 ， 
这 样 一 层 一 层 地 传递 下 去 就 完成 了 整个 View 树 的 layout 过 程 。 
setChildFrame 方 法 的 实现 如 下 所 示 。 


private void setChildFrame(View child,int left,int top,int 
width, int 
height) { 
child.layout(left, top, left + width,top + height); 
} 


RKINERE, setChildFrame F FJwidthflheigt In EMET ILA 
的 测量 宽 / 高 ， 从 下 面 的 代码 可 以 看 出 这 一 点 : 


final int childwidth = child.getMeasuredWidth(); 
final int childHeight = child.getMeasuredHeight(); 
setChildFrame(child, childLeft, childTop t 
getLocationOffset(child), 
childwidth, childHeight ) ; 


而 在 layout 方 法 中 会 通过 setFrame 去 设置 子 元 素 的 四 个 顶点 的 位 
置 ， 在 setFrame 中 有 如 下 几 人 句 赋值 语句 ， 这 样 一 来 子 元 素 的 位 置 就 确 
ES: 


mLeft = left; 
mTop = top; 
mRight = right; 


mBottom = bottom; 


下 面 我 们 来 回答 一 个 在 4.3.2 节 中 提 到 的 问题 : View 的 测量 宽 / 高 和 
最 终 / 宽 高 有 什么 区 别 ? 这 个 问题 可 以 具体 为 : View 的 
getMeasuredWidth 和 getWidth 这 WS TIE RBH AK A, BT 
getMeasuredHeight 和 getHeight 的 区 别 和 前 两 者 完全 一 样 。 为 了 回答 这 
个 问题 ， 首 先 ， 我 们 看 一 下 getwidth 和 getHeight 这 两 个 方法 的 具体 实 
现 : 


public final int getwidth() { 
return mRight -mLeft; 

} 

public final int getHeight() { 
return mBottom -mTop; 


} 


从 getWidth 和 getHeight HY WR 49 H 26 $ mLeft > mRight > mTop 和 
mBottom 这 四 个 变量 的 赋值 过 程 来 看 ，getWidth 方 法 的 返回 值 刚 好 残 是 
View 的 测量 宽度 ， 而 getHeight 方 法 的 返回 值 也 刚好 就 是 View 的 测量 高 
度 。 经 过 上 述 分 析 ， 现 在 我 们 可 以 回答 这 个 问题 了 : 在 View 的 默认 实 
现 中 ，View 的 测量 宽 / 高 和 最 终 宽 /高 是 相等 的 ， 只 不 过 测量 览 /高 形成 


于 View 的 measure 过 程 ， 而 最 终 视 /高 形成 于 View 的 layout 过 程 ， 即 两 者 
的 赋值 时 机 不 同 ， 测 量 宽 / 高 的 赋值 时 机 稍微 时 一些。 因此 ， 在 日 党 开 
发 中 ， 我 们 可 以 认为 View 的 测量 贤 / 高 就 等 于 最 终 贤 /高 ， 但 是 的 确 存 
在 某 些 特殊 情况 会 导致 两 者 不 一 致 ， 下 面 举 例 说 明 。 


如 果 重 写 View 的 layout 方 法 ， 代 码 如 下 : 


public void layout(int 1,int t,int r,int b) { 
super.layout(1,t,r + 100,b + 100); 
} 


上 述 代 码 会 导致 在 任何 情况 下 View 的 最 终 宽 /高 总 是 比 测量 宽 / 高 
大 100px， 虽 然 这 样 做 会 导 臻 View 显示 不 正常 并 且 也 没有 实际 意义 ， 
但 是 这 证 明了 测量 宽 / 高 的 确 可 以 不 等 于 最 终 宽 /高 。 另 外 一 种 情况 是 
在 某 些 情 况 下 ，View 需 要 多 次 measure 才 能 确定 目 己 的 测量 宽 / 高 ， 在 
前 几 次 的 测量 过 程 中 ， 其 得 出 的 测量 宽 / 高 有 可 能 和 最 终 宽 /高 不 一 
致 ， 但 最 终 来 说 ， 测 量 宽 /高 还 是 和 最 终 视 /高 相同 。 


4.3.3 draw 过 程 


Draw 过 程 束 比较 人 简单 了 ， 它 的 作用 是 将 View 绘 制 到 屏幕 上 面 。 
View 的 绘制 过 程 遭 循 如 下 几 步 : 


(1) 绘制 背景 background.draw(canvas)。 
(2) 绘制 自己 (onDraw) 。 


(3) 绘制 children (dispatchDraw) 。 


(4) 绘制 装饰 (onDrawScrollBars) ° 


这 一 点 通过 draw 方 法 的 源码 可 以 明显 看 出 来 ， 如 下 所 示 。 


View 绘 制 过 程 的 传递 是 通过 dispatchDraw 来 实现 的 ，dispatchDraw 
会 亿 历 调用 所 有 子 元 素 的 draw 方 法 ， 如 此 draw 事 件 就 一 层 层 地 传递 了 
下 去 。View 有 一 个 特殊 的 方法 setWillNotDraw， 先 看 一 下 它 的 源码 ， 
如 下 所 示 。 


per 
* If this view doesn't do any drawing on its own,set this 
flag to 
* allow further optimizations. By default,this flag is 
not set on 
* View, but could be set on some View subclasses such as 
ViewGroup. 
* 
> Typically, if you override {@link 
#onDraw(android.graphics.Canvas)} 
* you should clear this flag. 
* 
* @param willNotDraw whether or not this View draw on its 
own 
gh 
public void setWillNotDraw(boolean willNotDraw) { 
setFlags(willNotDraw ? WILL_NOT_DRAW : 0,DRAW_MASK) ; 


从 setWillNotDraw 这 个 方法 的 注释 中 可 以 看 出 ， 如 果 一 个 View 不 
绘制 任何 内 容 ， 那 么 设置 这 个 标记 位 为 tue 以 后 ， 系 统 会 进行 相 
应 的 优化 。 默 认 情 况 下 ，YView 没 有 局 用 这 个 优化 标记 位 ， 但 是 


ViewGroup 会 默认 启用 这 个 优化 标记 位 。 这 个 标记 位 对 实际 开发 的 意 
Mot: 当 我 们 的 自 定义 控件 继承 于 ViewGroup 并 且 本 身 不 具备 绘制 功 
能 时 ， 就 可 以 开启 这 个 标记 位 从 而 便于 系统 进行 后 续 的 优化 。 当 然 ， 
当 明 确 知道 一 个 ViewGroup 需 要 通过 onDraw 来 绘制 内 容 时 ， 我 们 需要 
显 式 地 关闭 WILL_NOT_DRAW 这 个 标记 位 。 


44 EFEM View 


本 节 将 详细 介绍 自 定 义 View 相 关 的 知识 。 目 定义 View 的 作用 不 用 
多 说 ， 这 个 读者 都 应 该 清楚 ， 如 果 想 要 做 出 绚丽 的 界面 效果 仅仅 靠 系 
统 的 控件 是 远 远 不 够 的 ， 这 个 时 候 束 必须 通过 目 定 义 View 来 实现 这 些 
绚丽 的 效果 。 自 定义 View 是 一 个 综合 的 技术 体系 ， 它 涉及 View 的 层次 
结构 、 事 件 分 发 机 制 和 View 的 工作 原理 等 搁 术 细 方 ， 而 这 些 技 术 细 节 
每 一 项 又 都 是 初学 者 难以 掌握 的 ， 因 此 束 不 难 理解 为 什么 初学 者 都 觉 
得 自 定义 View 很 难 这 一 现状 了 。 考 虚 到 这 一 点 ， 本 书 在 第 3 章 和 第 4 章 
的 前 半 部 分 对 自 定义 View 的 各 种 技术 细节 都 做 了 详细 的 分 析 ， 目 的 就 
是 为 了 让 读者 更 好 地 掌握 本 市 的 内 容 。 尽 管 自 定义 View 很 难 ， 甚 至 面 
对 各 种 复杂 的 效 采 时 往往 还 会 觉得 有 点 无 半 可 循 。 但 是 ， 本 市 将 从 一 
定局 度 来 重新 审视 上 自 定 义 View， 并 以 综述 的 形式 介绍 目 定 义 View 的 分 
类 和 须知 ， 虽 在 帮助 初学 者 能 够 透 过 现象 看 本 质 ， 避 免 陷 入 只 见 树木 
不 见 森 林 的 状态 之 中 。 同 时 为 了 让 读者 更 好 地 理解 自 定义 View， 在 本 
廊 最 后 还 会 针对 目 定 义 View 的 不 同类 别 分 别提 供 一 个 实际 的 例子 ， 通 
过 这 些 例子 能 够 让 读者 更 深入 地 掌握 自 定义 View © 


4.4.1 目 定 义 View 的 分 类 


目 定义 View 的 分 类 标准 不 唯一 ， 而 笔者 则 把 目 定义 View 分 为 4 
HE o 


1. 继承 View 重 写 onDraw 方 法 


这 种 方法 主要 用 于 实现 一 些 不 规则 的 效 采 ， 即 这 种 效果 不 方便 通 
过 布局 的 组 合 方式 来 达到 ， 往 往 需要 静态 或 者 动态 地 显示 一 些 不 规则 
的 图 形 。 很 显然 这 需要 通过 绘制 的 方式 来 实现 ， 即 重 写 onDraw 方 法 。 
采用 这 种 方式 需要 上 自己 支持 wrap_content， 并 有 日 padding 也 需要 上 自己 处 
Ho 


2. 继承 ViewGroup 派 生 特 殊 的 Layonut 


这 种 方法 主要 用 于 实现 目 定 义 的 布局 ， 即 除了 LinearLayout ` 
RelativeLayout、FrameLayout 这 几 种 系统 的 布局 之 外 ， 我 们 重新 定义 
一 种 新 布 局 ， 当 某 种 效果 看 起 来 很 像 几 种 View 组 合 在 一 起 的 时 候 ， 可 
以 采用 这 种 方法 来 实现 。 采 用 这 种 方式 稍微 复杂 一 些 ， 需 要 合适 地 处 
理 ViewGroup 的 测量 、 布 局 这 两 个 过 程 ， 并 同时 处 理子 元 素 的 测量 和 
布局 过 程 。 


3. 继承 特定 的 View (比如 TextView) 


这 种 方法 比较 常见 ， 一 般 是 用 于 扩展 某 种 已 有 的 View 的 功能 ， 比 
如 TextView， 这 种 方法 比较 容易 实现 。 这 种 方法 不 需要 自己 支持 


wrap_content 和 padding 等 。 


4. 继承 特定 的 ViewGroup (比如 LinearLayout) 


这 种 方法 也 比较 常见 ， 当 某 种 效 采 看 起 来 很 像 儿 种 View 组 合 在 一 
起 的 时 候 ， 可 以 采用 这 种 方法 来 实现 。 采 用 这 种 方法 不 需要 自己 处 理 


ViewGroup 的 测量 和 布局 这 两 个 过 程 。 需 要 注意 这 种 方法 和 方法 2 的 区 
别 ， 一 般 来 说 方法 2 能 实现 的 效果 方法 4 也 都 能 实现 ， 两 者 的 主要 差别 
在 于 方法 2 更 接近 View 的 底层 > 


上 面 介 绍 了 目 定义 View 的 4 种 方式 ， 读 者 可 以 仔细 体会 一 下 ， 是 
不 是 的 确 可 以 这 么 划分 ? 但 是 这 里 要 说 的 是 ， 目 定义 View 讲 究 的 是 灵 
活性 ， 一 种 效果 可 能 多 种 方法 都 可 以 实现 ， 我 们 需要 做 的 就 古 找到 一 
种 代价 最 小 、 最 高 效 的 方法 去 实现 ， 在 4.4.2 让 会 列举 一 些 自 定义 View 
过 程 中 常见 的 注意 事项 。 


4.4.2” 目 定义 View 须 知 


本 市 将 介绍 目 定义 View 过 程 中 的 一 些 注意 事项 ， 这 些 问 题 如 果 处 
理 不 好 ， 有 些 会 影响 View 的 正常 使 用 ， 而 有 些 则 会 导致 内 存 泄 露 等 ， 
具体 的 注意 事项 如 下 所 示 。 


1. 让 View 支 持 wrap_content 


这 是 因为 直接 继承 View 或 者 ViewGroup 的 控件 ， 如 果 不 在 
onMeasure 中 对 wrap_content 做 特殊 处 理 ， 那 么 当 外 界 在 布局 中 使 用 
wrap_content 时 束 无 法 达到 预期 的 效 采 ， 具 体 情形 已 经 在 4.3.1 市 中 进行 
了 详细 的 介绍 ， 这 里 不 再 重复 了 。 


2. 如 果 有 必要 ， 让 你 的 View 文 持 padding 


这 是 因为 直接 继承 View 的 控件 ， 如 果 不 在 draw 方 法 中 人 处理 
padding, ， 那 么 padding 属 性 是 无 法 起 作用 的 。 另 外 ,， 直 搂 继 承 目 
ViewGroup 的 控件 需要 在 onMeasure 和 onLayout 中 考虑 padding 和 子 元 素 


的 margin 对 其 造成 的 影响 ， 不 然 将 导致 padding 和 子 元 素 的 margin 失 
效 。 


3. 尽量 不 要 在 View 中 使 用 Handler， 没 必要 


这 是 因为 View 内 部 本 里 束 提供 了 post 系 列 的 方法 ， 完 全 可 以 蔡 代 
Handler 的 作用 ， 当 然 除非 你 很 明确 地 要 使 用 Handler 来 发 送 消 轧 。 


4. View 中 如 果 有 线程 或 者 动画 ， 需 要 及 时 停止 ， 参 考 


View#onDetachedFromWindow 


这 一 条 也 很 好 理解 ， 如 条 有 线程 或 者 动画 需要 停止 时 ， 那 么 
onDetachedFromWindow 是 一 个 很 好 的 时 机 。 当 包含 此 View 的 Activity 
退出 或 者 当前 View 被 remove 上 时 ，View 的 onDetachedFromWindow 方 法 
会 被 调用 ， 和 此 方法 对 应 的 是 onAttachedToWindow， 当 包含 此 View 的 
Activity 启 动 时 ，View 的 onAttachedToWindow 方 法 会 被 调用 。 同 时 ， 当 
View 变 得 不 可 见 时 我 们 也 需要 停止 线程 和 动画 ， 如 果 不 及 时 处 理 这 种 
问题 ， 有 可 能 会 造成 内 存 泄 漏 。 


5. View 带 有 滑动 典 套 情形 时 ， 需 要 处 理 好 滑动 冲突 
如 果 有 滑动 冲突 的 话 ， 那 么 要 合适 地 处 理 滑动 冲突 ， 否 则 将 会 严 
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的 例子 再 结合 上 面 两 节 的 内 容 ， 可 以 让 读者 更 好 地 掌握 目 定义 View。 
下 面 仍然 按照 目 定义 View 的 分 类 来 介绍 具体 的 实现 细节 。 


1. 继承 View 重 写 onDraw 方 法 


这 种 方法 主要 用 于 实现 一 些 不 规则 的 效果 ， 一 般 需 要 重 写 onDraw 
方法 。 采 用 这 种 方式 需要 目 己 文 持 wrap_content， 并 且 padding 也 需要 
目 己 处 理 。 下 面 通 过 一 个 具体 的 例子 来 演示 如 何 实 现 这 种 目 定义 


View ° 


为 了 更 好 地 展示 一 些 平时 不 容易 注意 到 的 问题 ， 这 里 选择 实现 一 
个 很 答 单 的 目 定 义 控件 ， 简 单 到 只 是 绘制 一 个 圆 ， 尽 管 如 此 ， 需 要 注 
意 的 细 下 还 是 很 多 的 。 为 了 实现 一 个 规范 的 控件 ， 在 实现 过 程 中 必须 
考虑 到 wrap_content 模 式 以 及 padding， 同 时 为 了 提高 便捷 性 ， 还 要 对 
外 提供 自 定 义 属性 。 我 们 先 来 看 一 下 最 简单 的 实现 ， 代 码 如 下 所 示 。 


public class CircleView extends View { 
private int mColor = Color.RED; 
private Paint mPaint = new 
Paint(Paint.ANTI_ALTIAS_ FLAG); 
public CircleView(Context context) { 
super (context); 
init(); 
J 


public CircleView(Context context,AttributeSet attrs) 


super (context,attrs); 


init(); 


上 面 的 代码 实现 了 一 个 具有 圆 形 效 果 的 目 定义 View， 它 会 在 目 己 
的 中 心 点 以 宽 / 高 的 最 小 值 为 直径 绘制 一 个 红色 的 实心 圆 ， 它 的 实现 很 
简单 ， 并 且 上 面 的 代码 相信 大 部 分 初学 者 都 能 写 出 来 ， 但 是 不 得 不 
说 ， 上 面 的 代码 只 有 是 一 种 初级 的 实现 ， 并 不 是 一 个 规范 的 目 定 义 
View， 为 什么 这 么 说 呢 ? 我 们 通过 调整 布局 参数 来 对 比 一 下 。 


请 看 下 面 的 布局 : 


<LinearLayout 
xmins:android="http://schemas.android.com/apk/res/android" 

xmins:tools="http://schemas.android.com/tools" 
android: Llayout_width="match_parent" 
android: Layout_height="match_parent" 
android:background="+ffffff" 
android:orientation="vertical" > 
<com.ryg.chapter_4.ui.CircleView 

android: id="@+id/circleViewi" 

android: Layout_width="match_parent" 

android: Layout_height="100dp" 

android: background="#000000"/> 


</LinearLayout> 


再 看 一 下 运行 的 效果 ， 如 图 4-3 中 的 (1) 所 示 ， 这 是 我 们 预期 的 
效果 。 接 着 再 调整 CircleView 的 布局 参数 ， 为 其 设置 20dp 的 margin， 调 
整 后 的 布局 如 下 所 示 。 


<com.ryg.chapter_4.ui.CircleView 
android:id="@+id/circleView1" 
android:layout_width=" match_parent" 
android:layout_height="100dp" 
android: Layout_margin="20dp" 


android: background="#000000"/> 


运行 后 看 一 下 效果 ， 如 图 4-3 中 的 (2) 所 示 ， 这 也 是 我 们 预期 的 
果 ， 这 说 明 margin 属 性 是 生效 的 。 这 是 因为 margin 属 性 是 由 父 容 絮 
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控制 的 ， 因 此 不 需要 在 CircleView 中 做 特殊 处 理 。 再 调整 CircleView 的 
布局 参数 ， 为 其 设置 20dp 的 padding， 如 下 所 示 。 


<com.ryg.chapter_4.ui.CircleView 
android:id="@+id/circleView1" 
android:layout_width="match_parent" 
android:layout_height="100dp" 
android:layout_margin="20dp" 
android:padding="20dp" 
android: background="#000000"/> 


运行 后 看 一 下 效果 ， 如 图 4-3 中 的 (3) 所 示 。 结 果 发 现 padding 根 
本 没有 生效 ， 这 就 是 我 们 在 前 面 提 到 的 直接 继承 和 目 View 和 ViewGroup 
的 控件 ，padding 是 默认 无 法 生效 的 ， 需 要 目 己 处 理 。 再 调整 一 下 
CircleView 的 布局 参数 ， 将 其 宽度 设置 为 wrap_content， 如 下 所 示 。 


<com.ryg.chapter_4.ui.CircleView 
android:id="@+id/circleView1" 
android: Layout_width="wrap_content" 
android: Llayout_height="100dp" 
android: Llayout_margin="20dp" 
android: padding="20dp" 
android: background="#000000"/> 


运行 后 看 一 下 效果 ， 如 图 4-3 中 的 (4) HR, BRAM 
wrap_content 并 没有 达到 预期 的 效果 。 对 比 下 (3) 和 “(4) 的 效果 图 ， 
发 现 视 度 使 用 wrap_content 和 使 用 match_parent 没 有 任何 区 别 。 的 确 是 
这 样 的 ， 这 一 点 在 前 面 也 已 经 提 到 过 : 对 于 直接 继承 自 View 的 控件 ， 


如 果 不 对 wrap_content 做 特殊 处 理 ， 那 么 使 用 wrap_content 就 相当 于 使 


FHmatch_parent ° 


图 4-3 ”CircleView 运 行 效果 图 


为 了 解决 上 面 提 到 的 几 种 问题 ， 我 们 需要 做 如 下 处 理 : 
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详细 的 介绍 ， 这 里 只 需要 指定 一 个 wrap_content 模 式 的 默认 宽 / 高 即 
可 ， a 宽 / 高 。 


其 次 ， 针 对 padding 的 问题 ， 也 很 简单 ， 只 要 在 绘制 鸭 时 候 考 虑 一 
下 padding 即 可 ， 因 此 我 们 需要 对 onDraw 稍 微 做 一 下 修改 ， 修 改 后 的 代 
码 如 下 所 示 。 


protected void onDraw(Canvas canvas) { 
super .onDraw(canvas); 
final int paddingLeft = getPaddingLeft(); 
final int paddingRight = getPaddingLeft(); 


final int paddingTop = getPaddingLeft(); 

final int paddingBottom = getPaddingLeft(); 

int width = getWidth() -paddingLeft -paddingRight; 

int height = getHeight() -paddingTop -paddingBottom; 

int radius = Math.min(width,height) / 2; 

canvas.drawCircle(paddingLeft + width / 2,paddingTop + 
height/2, radius, 


mPaint); 
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的 空 日 即 可 ， 其 中 国 心 和 半径 都 会 考虑 到 View 四 周 的 padding， 从 而 做 
相应 的 调整 。 


<com.ryg.chapter_4.ui.CircleView 
android:id="@+id/circleView1" 
android:layout_width="wrap_content" 
android:layout_height="100dp" 
android:layout_margin="20dp" 
android:padding="20dp" 
android: background="#000000"/> 


针对 上 面 的 布局 参数 ， 我 们 再 次 运行 一 下 ， 结 果 如 图 4-4 中 的 
(1) 所 示 ， 可 以 发 现 布局 参数 中 的 wrap_content 和 padding 均 生效 了 。 


图 4-4 ”CircleView 运 行 效 果 图 


最 后 ， 为 了 让 我 们 的 View 更 加 容易 使 用 ,很 多 情况 下 我 们 还 需要 
为 其 提供 目 定 义 属性 ， 像 android:layout_width 和 android:padding 这 种 以 
android 开 头 的 属性 是 系统 目 带 的 属性 ， 那 么 如 何 添加 目 定 义 属 性 呢 ? 
这 也 不 是 什么 难事 ， 尊 循 如 下 几 步 : 


第 一 步 ， 在 values 目 录 下 面 创建 自 定 义 属性 的 XML， 比 如 
attrs.xml， 也 可 以 选择 类 似 于 attrs_circle_view.xml 等 这 种 以 attrs_ 开 头 的 
文件 名 ， 当 然 这 个 文件 名 并 没有 什么 限制 ， 可 以 随便 取 名 字 。 针 对 本 
例 来 说 ， 选 择 创 建 attrs.xml 文 件 ， 文 件 内 容 如 下 : 


<?xml version="1.0" encoding="utf -8"?> 
<resources> 
<declare-styleable name="CircleView"> 
<attr name="circle_color" format="color" /> 
</declare-styleable> 


</resources> 


在 上 面 的 XML 中 声明 了 一 个 目 定 义 属 性 集合 “CircleView”， 在 这 
个 集合 里 面 可 以 有 很 多 目 定 义 属性 ， 这 里 只 定义 了 一 个 格式 
为 “color 的 属性 “circle_color”， 这 里 的 格式 color 指 的 是 颜色 。 除 了 颜 
色 格 式 ， 目 定义 属性 还 有 其 他 格式 ， 比 如 reference 是 指 资源 id , 


dimension 是 指 尺寸 ， 而 像 string、integer 和 boolean 这 种 是 指 基本 数据 类 
型 。 除 了 列举 的 这 些 还 有 其 他 类 型 ， 这 里 束 不 一 一 摘 述 了 ， 读 者 查看 
一 下 文档 即 可 ， 这 并 没有 什么 难度 。 


第 二 步 ， 在 View 的 构造 方法 中 解析 目 定 义 属 性 的 值 并 做 相应 处 
理 。 对 于 本 例 来 说 ， 我 们 需要 解析 circle_color 这 个 属性 的 值 ， 代 码 如 
BATA ° 


public CircleView(Context context,AttributeSet attrs,int 
defStyleAttr) { 
super (context, attrs,defStyleAttr); 
TypedArray a = 
context.obtainStyledAttributes(attrs,R.styleable.CircleView); 
mColor = 
a.getColor(styleable.CircleView_circle_color,Color.RED); 
a.recycle(); 
init(); 


} 


这 看 起 来 很 简单 ， 首 移 加 载 目 定义 属性 集合 CircleView， 接 着 解 
NT CircleView 属性 集合 中 的 circdle color 属性 ， 它 的 id 为 
R.styleable.CircleView_circle_color。 在 这 一 步骤 中 ， 如 采 在 使 用 时 没 
有 指定 circle_color 这 个 属性 ， 那 么 融会 选择 红色 作为 默认 的 颜色 值 ， 
解析 完 目 定义 属性 后 ， 通 过 recycle 方 法 来 实现 资源 ， 这 样 CircleView 中 
所 做 的 工作 就 完成 了 。 


第 三 步 ， 在 布局 文件 中 使 用 目 定 义 属性 ， 如 下 所 示 。 


<LinearLayout 
xmins:android="http://schemas.android.com/apk/res/android" 
xmins:app="http://schemas.android.com/apk/res-auto" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android:background="+ffffff" 
android:orientation="vertical" > 
<com.ryg.chapter_4.ui.CircleView 
android:id="@+id/circleView1" 
android:layout_width="wrap_content" 
android:layout_height="100dp" 
android:layout_margin="20dp" 
app:circle_color="@color/light_green" 
android:padding="20dp" 
android: background="#000000"/> 


</LinearLayout> 


上 上面 的 布局 文件 中 有 一 点 需要 注意 ， 首 和 完 ， 为 了 使 用 自 定 义 属 
E, MM TE Ti my XC fF P OS DM schemas 声明 
xmlns:app=http://schemas.android.com/apk/res-auto ° AX ^E AA, app 
是 目 定 义 属性 的 前 缀 ， 当 然 可 以 换 其 他 和 名字， 但 是 CircleView 中 的 目 
定义 属性 的 前 绥 必 须 和 这 里 的 一 致 ， 然 后 承 可 以 在 CircleView 中 使 用 
自 定 义 属性 了 ， 比 如 : app:circle_color="(Ocolor/light_green" ° 另外 ， 
也 有 按照 如 下 方 xt Æ BH schemas 
xmlns:app=http://schemas.android.com/apk/res/com.ryg.chapter 4 ， 这 种 


方式 会 在 apkres/ 后 面 附加 应 用 的 包 名 。 但 是 这 两 种 方式 并 没有 本 质 区 


别 ， 笔 者 比较 喜欢 的 是 xmlns:app=http://schemas.android.com/apk/res- 
auto 这 种 声明 方式 。 


到 这 里 自 定义 属性 的 使 用 过 程 就 完成 了 ， 运 行 一 下 程序 ， 效 果 如 
图 4-4 中 的 (2) 所 示 ， 很 显然 ，CircleView 的 自 定义 属性 circle_color 和 后 
效 了 。 下 面 给 出 CirclevView 的 完整 代码 ， 这 时 的 CircleView 已 经 是 一 个 
很 规范 的 目 定义 View 了 ， 如 下 所 示 。 


setMeasuredDimension(widthSpecSize, 200); 


} 


@Override 
protected void onDraw(Canvas canvas) { 
super.onDraw(canvas); 
final int paddingLeft = getPaddingLeft(); 
final int paddingRight = getPaddingleft(); 
final int paddingTop = getPaddingLeft(); 
final int paddingBottom = getPaddingLeft(); 
int width = getWidth() -paddingLeft -paddingRight; 
int height = getHeight() -paddingTop - 
paddingBottom; 
int radius = Math.min(width, height) / 2; 
canvas.drawCircle(paddingLeft + width / 
2,paddingTop + height / 2, 


radius,mPaint); 


2. 继承 ViewGroup 派 生 特殊 的 Layout 


这 种 方法 主要 用 于 实现 自 定义 的 布局 ， 采 用 这 种 方式 稍微 复杂 一 
些 ， 需 要 合适 地 处 理 ViewGroup 的 测量 、 布 局 这 两 个 过 程 ， 并 同时 处 
理子 元 系 的 测量 和 布局 过 程 。 在 第 3 章 的 3.5.3 节 中 ， 我 们 分 析 了 滑动 神 
突 的 两 种 方式 并 实现 了 两 个 目 定义 View: HorizontalScroll-ViewEx 和 


StickyLayout， 其 中 HorizontalScrollViewEx 就 是 通过 继承 ViewGroup 来 
实现 的 目 定 义 View， 这 里 会 再 次 分 析 它 的 measure 和 layout 过 程 。 


需要 说 明 的 是 ， 如 果 要 采用 此 种 方法 实现 一 个 很 规范 的 目 定义 
View， 是 有 一 定 的 代价 的 ， 这 点 通过 查看 LinearLayout 等 的 源码 束 知 
a, 它们 的 实现 都 很 复杂 。 对 于 Horizontal-ScrollViewEx 来 说 ， 这 里 不 
打算 实现 它 的 方方面面 ， 仅 仅 是 完成 主要 功能 ， 但 是 需要 规范 化 的 地 
方 会 给 出 说 明 。 


这 里 再 回顾 一 下 HorizontalScrollViewEx 的 功能 ， 它 主要 是 一 个 类 
似 于 ViewPager 的 控件 ， 也 可 以 说 是 一 个 类 似 于 水 平方 癌 的 
LinearLayout 的 控件 ， 它 内 部 的 子 元 素 可 以 进行 水 平滑 动 并 且 子 元 素 的 
内 部 还 可 以 进行 竖 直 滑动 ， 这 显然 是 存在 滑动 冲突 的 ， 但 是 
HorizontalScrollViewEx 内 部 解决 了 水 平和 竖 直 方 癌 的 滑动 冲突 问题 。 
天 于 HorizontalScrollViewEx 是 如 何 解 决 滑 动 冲 突 的 ， 请 参看 第 3 章 的 相 
天 内 容 。 这 里 有 一 个 假设 ， 那 就 是 所 有 子 元 素 的 览 / 高 都 是 一 样 的 。 下 
面 主 要 看 一 下 它 的 onMeasure 和 onLayout 方 法 的 实现 ， 先 看 
onMeasure， 如 下 所 示 。 


protected void onMeasure(int widthMeasureSpec, int 
heightMeasureSpec) { 
super .onMeasure(widthMeasureSpec, heightMeasureSpec); 
int measuredwidth = 0; 
int measuredHeight = 0; 
final int childCount = getChildCount(); 
measureChildren(widthMeasureSpec, heightMeasureSpec); 
int widthSpaceSize = 


MeasureSpec.getSize(widthMeasureSpec); 


int widthSpecMode = 
MeasureSpec.getMode(widthMeasureSpec ) ; 
int heightSpaceSize = 
MeasureSpec.getSize(heightMeasureSpec); 
int heightSpecMode = 
MeasureSpec.getMode(heightMeasureSpec); 
if (childCount == 0) { 
setMeasuredDimension(0,0); 
} else if (widthSpecMode == MeasureSpec.AT_MOST && 
heightSpecMode == 
MeasureSpec.AT_MOST) { 
final View childView = getChildAt (0); 
measuredwidth = childView.getMeasuredwidth() * 
childCount; 


measuredHeight = childView.getMeasuredHeight(); 


setMeasuredDimension(measuredwidth, measuredHeight); 
} else if (heightSpecMode == MeasureSpec.AT_MOST) { 
final View childView = getChildAt (0); 


measuredHeight = childView.getMeasuredHeight(); 


setMeasuredDimension(widthSpaceSize, childView.getMeasured- 
Height()); 
} else if (widthSpecMode == MeasureSpec.AT_MOST) { 
final View childView = getChildAt (0); 
measuredwidth = childView.getMeasuredwidth() * 


childCount; 


setMeasuredDimension(measuredwidth, heightSpaceSize) ; 
} 
} 


这 里 说 明 一 下 上 述 代码 的 逻辑 ， 首 先 会 判断 是 否 有 子 元 素 ， 如 末 
没有 子 元 素 就 直接 把 自己 的 览 /高 设 为 0， 然 后 束 是 判断 蜗 和 高 是 不 是 
采用 了 wrap content ， 如 果 宽 采用 了 wrapcontent , AB A 
HorizontalScrollViewEx 的 宽度 束 是 所 有 子 元 素 的 宽度 之 和 ; 如 果 高 度 
采用 了 wrap_content， 那 么 HorizontalScrollViewEx 的 高 度 就 是 第 一 个 子 
元 素 的 高 度 。 


上 述 代 码 不 太 规 范 的 地 方 有 两 点 : 第 一 点 是 没有 子 元 素 的 时 候 不 
应 该 直接 把 沉 / 高 设 为 0， 而 应 该 根据 LayoutParams 中 的 宽 / 高 来 做 相应 
AH, 第 二 点 是 在 测量 HorizontalScrollViewEx 的 宽 / 高 时 没有 考虑 到 它 
的 padding 以 及 子 元 素 的 margin， 为 它 的 padding 以 及 子 元 素 的 margin 
会 影响 到 HorizontalScrollViewEx 的 宽 / 高 。 这 是 很 好 理解 的 ， 因 为 不 管 
æ A OA padding We FR AN margin, CA HE 
HorizontalScrollViewEx 的 空间 。 


接着 再 看 一 下 HorizontalScrollViewEx 的 onLayout 方 法 ， 如 下 所 
ZN o 


protected void onLayout(boolean changed, int 1,int t,int 
r,int b) { 
int childLeft = 0; 
final int childCount = getChildCount(); 


mChildrenSize = childCount; 


for (int i = 0; i < childCount; i++) { 
final View childView = getChildAt(i); 
if (childView.getVisibility() != View.GONE) { 
final int childwidth = 
childView.getMeasuredwWidth(); 
mChildwidth = childwidth; 
childView.layout(childLeft,0,childLeft 
+ childwidth, 


childView.getMeasuredHeight()); 
childLeft += childwidth; 


上 述 代 码 的 逻辑 并 不 复杂 ， 其 作用 是 完成 子 元 素 的 定位 。 首 移 会 
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瓯 通过 layout 方 法 将 其 放置 在 合适 的 位 置 上 。 从 代码 上 来 看 ， 这 个 放置 
过 程 是 由 左 回 右 的 ， 这 和 水 平方 向 的 LinearLayout 比 较 类 似 。 上 壕 代码 
的 不 完美 之 处 仍然 在 于 放置 子 元 素 的 过 程 没有 考虑 到 自身 的 padding 以 
及 子 元 素 的 margin， 而 从 一 个 规范 的 控件 的 角度 来 看 ， 这 些 都 是 应 该 
考虑 的 。 下 面 给 出 Horizontal-ScrollViewEx 的 完整 代码 ， 如 下 所 示 。 


public class HorizontalScrollViewEx extends ViewGroup { 
private static final String TAG = 
"HorizontalScrollViewEx"; 


private int mChildrenSize; 


J 

@Override 

protected void onDetachedFromWindow() { 
mVelocityTracker.recycle(); 


super .onDetachedFromWindow(); 


} 


继承 特定 的 View (比如 TextView) 和 继承 特定 的 ViewGroup (HE 
如 LinearLayout) 这 两 种 方式 比较 简单 ， 这 里 就 不 再 举例 说 明了 ， 关 于 
第 3 章 中 提 到 的 StickyLayout 的 具体 实现 ， 大 家 可 以 参看 笔者 在 Github 
EN FW H H : https:/github.com/singwhatiwanna/Pinned- 
HeaderExpandableListView ° 


4.4.4” 自 定义 View 的 思想 


到 这 里 ， 自 定义 View 相 关 的 知识 都 已 经 介绍 完了 ， 可 能 读者 还 是 
觉得 有 点 模糊 。 前面 说 过 ， 自 定义 View 是 一 个 综合 的 技术 体系 ， 很 多 
情况 下 需要 灵活 地 分 析 从 而 找 出 最 高 效 的 方法 ， 因 此 本 章 不 可 能 去 分 
析 一 个 个 具体 的 自 定 义 View 的 实现 ， 因 为 自 定 义 View 五 化 八 门 ， 是 不 
可 能 全 部 分 析 一 遍 的 。 虽 然 我 们 不 能 把 自 定 义 View 都 分 析 一 沉 ， 但 是 
我 们 能 够 提取 出 一 种 思想 ， 在 面 对 陌 生 的 自 定 义 View 时 ， 运 用 这 个 思 
想 去 快速 地 解决 问题 。 这 种 思想 的 描述 如 下 : 首先 要 掌握 基本 功 ， 比 
如 View 的 弹性 滑动 、 滑 动 冲 突 、 绘 制 原理 等 ， 这 些 东 西 都 是 自 定义 
View 所 必须 的 ， 尤 其 是 那些 看 起 来 很 炫 的 目 定义 View， 它 们 往往 对 这 


些 技术 点 的 要 求 更 高 ;熟练 掌握 基本 功 以 后 ， 在 面 对 痢 的 目 定义 View 
时 ， 要 能 够 对 其 分 类 并 选择 合适 的 实现 思路 ， 目 定义 View 的 实现 方法 
的 分 类 在 4.4.1 市 中 已 经 介绍 过 了 ; 另外 平时 还 需要 多 积累 一 些 目 定义 
View 相 关 的 经 验 ， 并 逐渐 做 到 融会 贯通 ， 通 过 这 种 思想 慢 慢 地 束 可 以 
提高 自 定义 View 的 水 平 了 。 


“5% HfffRemoteViews 


本 章 所 讲述 的 主题 是 RemoteViews ， 从 名 字 可 以 看 出 ， 
RemoteViews 应 该 是 一 种 远程 View， 那 么 什么 是 远程 View 呢 ? 如果 说 
远程 服务 可 能 比较 好 理解 ， 但 是 远程 View 的 确 没 听 说 过 ， 其 实 它 和 远 
程 Service 是 一 样 的 ，RemoteViews 表 示 的 是 一 个 View 结 构 ， 它 可 以 在 
其 他 进程 中 显示 ， 由 于 它 在 其 他 进程 中 显示 ， 为 了 能 够 更 新 它 的 界 
面 ，RemoteViews 提 供 了 一 组 基础 的 操作 用 于 跨 进 程 更 新 它 的 界面 。 
这 上 听 起 来 有 点 神奇 ， 竞 然 能 跨 进 程 更 狐 界 面 ! 但 是 RemoteViews 的 确 
能 够 实现 这 个 效果 。RemoteViews 在 Android 中 的 使 用 场景 有 两 种 : 通 
知 栏 和 桌面 小 部 件 ， 为 了 更 好 地 分 析 RemoteViews 的 内 部 机 制 ， 本 章 
先 人 简单 介绍 RemoteViews 在 通知 栏 和 桌面 小 部 件 上 的 应 用 ， 接 着 分 析 
RemoteViews 的 内 部 机 制 ， 最 后 分 析 RemoteViews 的 意义 并 给 出 一 个 采 
用 RemoteViews 来 跨 进 程 更 新 界面 的 示例 。 


5.1 RemoteViews 的 应 用 


RemoteViews 在 实际 开发 中 ， 主 要 用 在 通知 栏 和 桌面 小 部 件 的 开 
发 过 程 中 。 通 知 栏 每 个 人 都 不 陌生， 主要 是 通过 NotificationManager 的 
notify 方 法 来 实现 的 ， 它 除了 默认 效果 外 ， 还 可 以 另外 定义 布局 。 宋 面 
小 部 件 则 是 通过 AppWidgetProvider 来 实现 的 ，AppWidget-Provider 本 质 
上 是 一 个 广播 。 通 知 柱 和 桌面 小 部 件 的 开发 过 程 中 都 会 用 到 
RemoteViews， 它 们 在 更 狐 界 面 时 无 法 像 在 Activity 里 面 那样 去 直接 更 
新 View， 这 是 因为 二 者 的 界面 都 运行 在 其 他 进程 中 ， 确 切 来 说 是 系统 


的 SystemServer 进 程 。 为 了 路 进程 更 新 界面 ，RemoteViews 提 供 了 一 系 

列 set 方 法 ， 并 且 这 些 方法 只 是 View 全 部 方法 的 子 集 ， 另 外 
a 2 00 这 一 点 会 在 5.2 节 中 进 
行 详细 说 明 。 下 面 简单 介绍 一 下 RemoteViews 在 通知 栏 和 桌面 小 部 件 
中 的 使 用 方法 ， 人 至 于 它们 更 详细 的 使 用 方法 请 读者 阅读 相关 资料 即 
可 ， 本 章 的 重点 是 分 析 RemoteViews 的 内 部 机 制 。 


5.1.1 ”RemoteViews 在 通知 栏 上 的 应 
用 


目 先 我 们 看 一 下 RemoteViews 在 通知 栏 上 的 应 用 ， 我 们 知道 ， 通 
知 栏 除 了 默认 的 效果 外 还 文 持 目 定义 布局 ， 下 面 分 别 说 明 这 两 种 情 
o 


使 用 系统 默认 的 样式 弹出 一 个 通知 是 很 简单 的 ， 代 码 如 下 : 


Notification notification = new Notification(); 
notification.icon = R.drawable.ic_launcher; 
notification.tickerText = "hello world"; 
notification.when = System.currentTimeMillis(); 
notification.flags = Notification.FLAG_AUTO_CANCEL; 
Intent intent = new Intent(this, DemoActivity_1.class); 
PendingIntent pendingIntent = 
PendingIntent.getActivity(this, 
0, intent, PendingIntent .FLAG_UPDATE_CURRENT) |; 


notification.setLatestEventInfo(this, "chapter_5","this is 


notification.", 


pendingIntent); 


NotificationManager manager = 


(NotificationManager)getSystemService 


(Context .NOTIFICATION_SERVICE); 


manager .notify(1,notification) ; 


上 述 代码 会 弹出 一 个 系统 默认 样式 的 通知 ， 单 击 通知 后 会 打开 
DemoActivity_1 同 时 会 清除 本 号 。 为 了 满足 个 性 化 需求 ， 我 们 还 可 能 
会 用 到 目 定 义 通 知 。 目 定义 通知 也 很 简单 ， 首 和 我 们 要 提供 一 个 布局 
文件 ， 然 后 通过 RemoteViews 来 加 载 这 个 布局 文件 即 可 改变 通知 的 样 


式 ， 代 码 如 下 所 示 


Notification 

notification. 
notification. 
notification. 


notification. 


Intent intent 


o 


notification = new Notification(); 
icon = R.drawable.ic_launcher; 
tickerText = "hello world"; 
when = System.currentTimeMillis(); 
flags = Notification.FLAG_AUTO_CANCEL; 
= new Intent(this,DemoActivity_1.class); 


PendingIntent pendingIntent = 


PendingIntent.getActivity(this, 


0, intent, PendingIntent .FLAG_UPDATE_CURRENT) ; 


RemoteViews remoteViews = new 


RemoteViews(getPackageName(),R.layout. 


layout_notification); 


remoteViews.setTextViewText(R.id.msg, "chapter_5"); 


MAEMNARA, BEATA EE H ElRemoteViews, H 
定义 通知 的 效果 如 图 5-1 所 示 。 
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图 5-1 “ 自 定义 通知 栏 样式 


RemoteViews 的 使 用 也 很 简单 ， 只 了 权 提 供 当 前 应 用 的 包 名 和 布局 
文件 的 资源 id 即 可 创建 一 个 RemoteViews 对 象 。 如 何 更 新 RemoteViews 
WE? 这 一 点 和 更 新 View 有 很 大 的 不 同 ， 更 新 RemoteViews 时 ， 无 法 直 
接 访 问 里 面 的 View， 而 必须 通过 RemoteViews 所 提供 的 一 系列 方法 来 
更 新 View。 比 如 设置 TextView 的 文本 ， 要 采用 如 下 方式 : 
remote Views.set Text View Text(R.id.msg,"chapter_5") 其 中 
setTextViewText 的 两 个 参数 分 别 为 TextView 的 id 和 要 设置 的 文本 。 而 设 
置 ImageView 的 图 片 也 不 能 直接 访问 ImageView， 必 须 通 过 如 下 方式 : 
remote Views.setImage ViewResource(R.id.icon,R.drawable.icon1) 
setImageViewResource 的 两 个 参数 分 别 为 InageView 的 id 和 要 设置 的 图 

资源 的 id。 如 果 要 给 一 个 控件 加 单 击 事件 ， 则 要 使 用 PendingIntent 并 


通 过 setOnClickPendinglntentt 7 法 来 实现 , 比 如 
remote Views.setOnClickPendingIntent(R.id.open_activity2,openActivity2P 
ending-Intent)iX 4) 1015 S 24 id WN open_activity2 A) View JH EEE F o 

天 于 PendingIntent， 它 表示 的 是 一 种 待定 的 Intent， 这 个 Intent 中 所 包含 
的 意图 必须 由 用 户 来 触发 。 为 什么 更 新 RemoteViews 如 此 复杂 呢 ? E 
观 原 因 是 因为 RemoteViews 并 没有 提供 和 View 类 似 的 findViewById 这 个 
方法 ， 因 此 我 们 无 法 获取 到 RemoteViews 中 的 子 View， 当 人 然 实 际 原 
绝 非 如 此 ， 具 体会 在 5.2 节 中 进行 详细 介绍 。 


5.1.2 ”RemoteViews 在 桌面 小 部 件 上 
的 应 用 


AppWidgetProvider 是 Android 中 提供 的 用 于 实现 和 更 面 小 部 件 的 类 ， 
其 本 质 是 一 个 广播 ， 即 BroadcastReceiver ， 图 5-2 所 示 的 是 它 的 类 继承 
关系 。 所 以 ， 在 实际 的 使 用 中 ， 把 AppWidgetProvider 当成 一 个 
BroadcastReceiver 束 可 以 了 ， 这 样 许多 功能 束 很 好 理解 了 。 


AppWidgetProvider - android.appwidget 
vO Object 
v ©* BroadcastReceiver 


P K2 APPWIG 


图 5-2 AppWidgetProvider 的 类 继承 关系 


为 了 更 好 地 展示 RemoteViews 在 蝎 面 小 部 件 上 的 应 用 ， 我 们 先 倘 
单 介绍 棍 面 小 部 件 的 开发 步骤 ， 分 为 如 下 几 步 。 


1. 定义 小 部 件 界面 


在 reslayout 下 新 建 一 个 XML 文件 ， 命 名 为 widget,xzml， 和 名称 和 内 
容 可 以 目 定 义 ， 看 这 个 小 部 件 要 做 成 什么 样子 ， 内 容 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmins:android="http://schemas.android.com/apk/res/android" 

android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android:orientation="vertical" > 
<ImageView 

android: id="@+id/imageView1" 

android: Layout_width="wrap_content" 

android: Layout_height="wrap_content" 

android: src="@drawable/iconi" /> 


</LinearLayout> 


2. 定义 小 部 件 配置 信息 


在 res/xml/ 下 新 建 appwidget_provider_info.xml， 名 称 随意 选择 ， 琢 
加 如 下 内 容 : 


<?xml version="1.0" encoding="utf-8"?> 
<appwidget - provider 
xmins:android="http://schemas.android.com/apk/res/android" 
android: initialLayout="@layout/widget" 


android:minHeight="84dp" 


LULA Be SCRA, initialLayout e787) TA Pre AA 
初始 化 布局 ，minHeight 和 minWidth 定 义 小 工具 的 最 小 尺寸 ， 
updatePeriodMillis 定 义 小 工具 的 上 自动 更 新 周期 ， 毫 秒 为 单位 ， 每 陋 一 
个 周期 ， 小 工具 的 自动 更 新 就 会 触发 。 


3. 定义 小 部 件 的 实现 类 


这 个 类 需要 继承 AppWidgetProvider， 代 人 码 如 下 : 


上 面 的 代码 实现 了 一 个 简单 的 桌面 小 部 件 ， 在 小 部 件 上 面 显 示 一 
张 图 片 ， 单 击 它 后 ， 这 个 图 片 就 会 旋转 一 周 。 当 小 部 件 被 添 加 a 到 桌面 


后 ， 会 通过 RemoteViews 来 加 载 布局 文件 ， 而 当 小 部 件 被 单 击 后 的 旋 
转 效 果 则 是 通过 不 断 地 更 新 RemoteViews 来 实现 的 ， 由 此 可 见 ， 桌 面 
小 部 件 不 管 是 初始 化 界面 还 是 后 续 的 更 新 界面 都 必须 使 用 


RemoteViews 来 完成 。 
4. 在 AndroidManifest.xml 中 声明 小 部 件 


这 是 最 后 一 步 ， 因 为 桌面 小 部 件 本 质 上 是 一 个 广播 组 件 ， 因 此 必 
须要 注册 ， 如 下 所 示 。 


<receiver 
android:name=".MyAppwWidgetProvider" > 
<meta-data 


android:name="android.appwidget.provider" 


android:resource="@xml/appwidget_provider_info"> 
</meta-data> 
<intent-filter> 
<action 
android:name="com.ryg.chapter_5.action.CLICK" /> 
<action 
android:name="android.appwidget.action.APPWIDGET_UPDATE" /> 
</intent-filter> 


</receiver> 


上 面 的 代码 中 有 两 个 Action， 其 中 第 一 个 Action 用 于 识别 小 部 件 的 
单 击 行为 ， 而 第 二 个 Action 则 作为 小 部 件 的 标识 而 必须 存在 ， 这 是 系 


统 的 规范 ， 如 果 不 加 ， 那 么 这 个 receiver 束 不 是 一 个 桌面 小 部 件 并 且 也 
无 法 出 现在 手机 的 小 部 件 列表 里 。 


法 ; 


AppWidgetProvider 除 了 最 常用 的 onUpdate 方 法 ， 还 有 其 他 几 个 方 
onEnabled、onDisabled、onDeleted 以 及 onReceive。 这 些 方法 会 自 


动 地 被 onReceive 方 法 在 合适 的 时 间 调 用 。 确 切 来 说 ， 当 广播 到 来 以 


IS, 


AppWidgetProvider 会 目 动 根据 广播 的 Action 通 过 onReceive 方 法 来 


目 动 分 发 广播 ， 也 就 是 调用 上 述 几 个 方法 。 这 几 个 方法 的 调用 时 机 如 
BATA ° 


onEnable: 当 该 窗口 小 部 件 第 一 次 添加 到 桌面 时 调用 该 方法 ， 可 
添加 多 次 但 只 在 第 一 次 调用 。 

onUpdate: 小 部 件 被 添加 时 或 者 每 次 小 部 件 更 新 时 都 会 调用 一 次 
该 方法 ， 小 部 件 的 更 新 时 机 由 updatePeriodMillis 来 指定 ， 每 个 周 
期 小 部 件 都 会 目 动 更 新 一 次 。 

onDeleted: 每 删除 一 次 桌面 小 部 件 就 调用 一 次 。 

onDisabled: 当 最 后 一 个 该 类 型 的 加 面 小 部 件 被 删除 时 调用 该 方 
法 ， 注 意 是 最 后 一 个 。 

onReceive: 这 是 广播 的 内 置 方法 ， 用 于 分 发 具体 的 事件 给 其 他 方 
148 


关于 AppWidgetProvider 的 onReceive 方 法 的 具体 分 发 过 程 ， 可 以 参 


看 源码 中 的 实现 ， 如 下 所 示 。 通 过 下 面 的 代码 可 以 看 出 ，onReceive 中 
会 根据 不 同 的 Action 来 分 别 调用 onEnable、onDisable 和 onUpdate 等 方 


1K ° 


public void onReceive(Context context,Intent intent) { 


// Protect against rogue update broadcasts (not really 


EEH TP ACP STB RE, PTR, I 
际 开发 中 会 稍微 复杂 一 些 ,但 是 开发 流程 是 一 样 的 。 可 以 发 现 ， 桌 面 
小 部 件 在 界面 上 的 操作 都 要 通过 Remote-Views， 不 管 是 小 部 件 的 界面 
初始 化 还 是 界面 更 新 都 必须 依赖 它 。 


5.1.3 PendingIntent 概 述 


在 5.1.2 玫 中 ， 我 们 多 次 提 到 PendingIntent， 那 么 PendingIntent 到 底 
是 什么 东西 呢 ? 它 和 tent 的 区 别 是 什么 呢 ? 在 本 节 中 将 介绍 
PendingIntent 的 使 用 方法 。 


顾名思义 ，PendingIntent 表 示 一 种 处 于 pending 状 态 的 意图 ， 而 
pending 状 态 表示 的 是 一 种 待定 、 等 待 、 即 将 发 生 的 意思 ， 就 是 说 接 下 
来 有 一 个 Intent ( 即 意 图 ) 将 在 某 个 待定 的 时 刻 发 生 。 可 以 看 出 
PendingIntent 和 Intent 的 区 别 在 于 ，PendingIntent 是 在 将 来 的 某 个 不 确 
定 的 时 刻 发 生 ， 而 Intent 是 立刻 发 生 。PendingIntent 典 型 的 使 用 场景 是 
给 RemoteViews 添 加 单 击 事 件 ， 因 为 RemoteViews 运 行 在 远程 进程 中 ， 
此 RemoteViews 不 同 于 普通 的 View， 所 以 无 法 直接 辐 View 那 样 通过 
setOnClickListener 方 法 来 设置 单 击 事件 。 要 想 给 RemoteViews 设 置 单 击 
事件 ， 束 必须 使 用 PendingIntent，PendingIntent 通 过 send 和 cancel 方 法 
来 发 送 和 取消 特定 的 待定 Intent 。 


PendingIntent 支 持 三 种 待定 意图 : 启动 Activity、 启 动 Service 和 发 
送 广播 ， 对 应 着 它 的 三 个 接口 方法 ， 如 表 5-1 所 示 。 


表 5-1 PendingIntent 的 主要 方法 


| | 


static getActivity(Context context, int requestCode, Intent 


PendingIntent | intent, int flags) 


获得 一 个 PendingIntent， 该 待定 意图 发 生 时 ， 效 果 
相当 于 


Context.startActivity(Intent) 


getService(Context context, int requestCode, Intent 


intent, int flags) 
jkt — PendingIntent, AERA AEM, BOR 
相当 于 


Context.startService(Intent) 


static 


PendingIntent 


getBroadcast(Context context, int requestCode, Intent 


intent, int flags) 
static 


获得 一 个 PendingIntent， 该 待定 意图 发 生 时 ， 效 果 
相当 于 


Context.sendBroadcast(Intent) 


PendingIntent 


如 表 5-1 所 示 ， RN 、getService 和 getBroadcast 这 三 个 方法 的 

参数 意义 都 是 相同 的 ， 第 一 个 和 第 三 个 参数 比较 好 理解 ， 这 里 主要 说 
下 第 二 个 参数 requestCode 和 第 四 个 参数 flags ， 其 中 requestCode 表 示 
PendingIntent 发 送 方 的 请 求 码 ， 多 数 情 况 下 设 为 0 即 可 ， 男 外 
requestCode 会 影响 到 flags 的 效果 。flags 常见 的 类 型 有 : 
FLAG ONE SHOT š FLAG_NO_CREATE ù 
FLAG_CANCEL_ CURRENT TIELAG _UPDATE_CURRENT 。 在 说 明 这 
四 个 标记 位 之 前 ， 必 须要 明白 一 个 概念 ， 那 就 是 PendingIntent 的 匹配 
规则 ， 即 在 什么 情 en 同 的 。 


PendingIntent 的 匹配 规则 为 : 如 果 两 个 PendingImtent 它 们 内 部 的 
Intent 相 同 并 且 requestCode 也 相同 ， 那 么 这 两 个 PendingImtent 残 是 相同 
的 。requestCode 相 同比 较 好 理解 ， 那 么 什么 情况 下 Intent 相 同 呢 ? 
Intent 的 匹配 规则 是 : 如 果 两 个 Intent 的 ComponentrName 和 intent-filter 都 
相同 ， 那 么 这 两 个 Intent 束 是 相同 的 。 需 要 注意 的 是 Extras 不 参与 Intent 
的 匹配 过 程 ， 只 要 Intent 之 间 的 ComponentName 和 intent-filter 相 同 ， 即 
使 它们 的 Extras 不 同 ， 那 么 这 两 个 mtent 也 是 相同 的 。 了 解 了 
PendingImtent 的 匹配 规则 后 ， 就 可 以 进一步 理解 fags 参 数 的 含义 了 ， 

如 下 所 示 。 


FLAG_ONE_SHOT 


= Bl fi wt AY PendingIntent HEREH—NR, AUR ERS RA D) 
cancel， 如 果 后 续 还 有 相同 的 PendingIntent， 那 么 它们 的 send 方 法 就 会 
调用 失败 。 对 于 通知 栏 消 息 来 说 ， 如 果 采 用 此 标记 位 ， 那 么 同类 的 通 
知 只 能 使 用 一 次 ， 后 续 的 通知 单 击 后 将 无 法 打开 。 


FLAG_NO_CREATE 


当前 摘 述 的 PendingIntent 不 会 主动 创建 ， 如 有 果 当 前 PendingIntent 之 
前 不 存在 ， 那 么 getActivity ` getServiceÁl an 直接 返回 
null， 即 获取 PendingIntent 失 败 。 这 个 标记 位 很 少见 ， 它 无 法 单独 使 
用 ， 因 此 在 日 常 开 发 中 它 并 没有 太 多 的 使 用 意义 ， 这 里 就 不 再 过 多 介 
AS 


FLAG_CANCEL_CURRENT 


当前 描述 的 PendingIntent 如 果 已 经 存在 ， 那 么 它们 都 会 被 cancel， 
然后 系统 会 创建 一 个 新 的 PendingIntent。 对 于 通知 栏 消 息 来 说 ， 那 些 


被 cancel 的 消息 单 击 后 将 无 法 打开 。 
FLAG_UPDATE_CURRENT 


当前 描述 的 PendingIntent 如 果 已 经 存在 ， 那 么 它们 都 会 被 更 新 ， 
即 它们 的 Intent 中 的 Extras 会 被 蔡 换 成 最 新 的 。 


从 上 面 的 分 析 来 看 还 是 不 太 好 理解 这 四 个 标记 位 ， 下 面 结合 通知 
栏 消 息 再 描述 一 再 。 这 里 分 两 种 情况 ， 如 下 代码 中 : 
managernotify(1notification)， 如 果 notify 的 第 一 个 参数 id 是 和 常量， 那么 
多 次 调用 notify 只 能 弹出 一 个 通知 ， 后 续 的 通知 会 把 前 面 的 通知 完全 替 
代 掉 ， 而 如 有 果 每 次 id 都 不 同 ， 那 么 多 次 调用 notify 会 弹出 多 个 通知 ， 下 
面 一 一 说 明 。 


如 采 notify 方 法 的 id 是 和 常量， 那么 不 管 PendingIntent 是 否 匹 配 ， 后 
面 的 通知 会 直接 替换 前 面 的 通知 ， 这 个 很 好 理解 。 


如 果 notify 方 法 的 id 每 次 都 不 同 ， 那 么 当 PendingIntent 不 匹配 时 , 
这 里 的 匹配 是 指 PendingIntent 中 的 Intent 相 同 并 且 requestCode 相 同 ， 在 
这 种 情况 下 不 管 采用 何 种 标记 位 ， 这 些 通知 之 间 不 会 相互 干扰 。 如 果 
PendingIntent 处 于 匹配 状态 时 ， 这 个 时 候 要 分 情况 讨论 : 如 采 采 用 了 
FLAG_ONE_SHOT 标 记 位 ， 那 么 后 续 通 知 中 的 PendingIntent 会 和 第 一 
条 通知 保持 完全 一 致 ， 包 括 其 中 的 Extras， 单 击 任何 一 条 通知 后 ， 晋 
下 的 通知 均 无 法 再 打开 ， 当 所 有 的 通知 都 被 清除 后 ， 会 再 次 重复 这 个 
过 程 ， 如 果 采 用 FLAG_CANCEL_CURRENT 标 记 人 位， 那么 只 有 最 新 的 
通知 可 以 打开 ， 之 前 弹出 的 所 有 通知 均 无 法 打开 ; 如 果 采 用 
FLAG_UPDATE_CURRENT 标 记 位 ， 那 么 之 前 弹出 的 通知 中 的 


PendingImtent 会 被 更 新 ， 最 终 它 们 和 最 新 的 一 条 通知 保持 完全 一 致 ， 
包括 其 中 的 Extras， 并 且 这 些 通知 都 是 可 以 打开 的 。 


5.2 RemoteViews 的 内 部 机 制 


RemoteViews 的 作用 是 在 其 他 进程 中 显示 并 更 新 View 界 面 ， 为 了 
更 好 地 理解 它 的 内 部 机 制 ， 我 们 先 来 看 一 下 它 的 主要 功能 。 首 先 看 一 
下 它 的 构造 方法 ， 这 里 只 介绍 一 个 最 常用 的 构造 方法 : public 
RemoteViews(String packageName,int layoutId)， 它 接受 两 个 参数 ， 第 一 
个 表示 当前 应 用 的 包 名 ， 第 二 个 参数 表示 待 加 载 的 布局 文件 ， 这 个 很 
好 理解 。RemoteViews 目 前 并 不 能 文 持 所 有 的 View 类 型 ， 它 所 文 持 的 
所 有 类 型 如 下 : 


Layout 
FrameLayout ` LinearLayout ` RelativeLayout ` GridLayout ° 
View 


AnalogClock ` Button > Chronometer > ImageButton ` ImageView > 
ProgressBar > TextView > ViewFlipper > ListView > GridView > 
StackView ` AdapterViewFlipper > ViewStub ° 


上 面 所 摘 述 的 是 RemoteViews 所 文 持 的 所 有 的 View 类 型 ， 
RemoteViews 不 文 持 它 们 的 子 类 以 及 其 他 View 类 型 ， 也 就 是 说 
RemoteViews 中 不 能 使 用 除了 上 述 列 表 中 以 外 的 View， 也 无 法 使 用 日 
定义 View。 比 如 如 采 我 们 在 通知 栏 的 RemoteViews 中 使 用 系统 的 
EditText， 那 么 通知 栏 消 息 将 无 法 弹出 并 且 会 抛 出 如 下 异常 : 


E/StatusBar(765): couldn't inflate view for notification 
com.ryg.chapter_ 
5/0x2 
E/StatusBar (765): android.view.InflateException: Binary XML 
file line #25: 
Error inflating class android.widget.EditText 
E/StatusBar (765): Caused by: android.view.InflateException: 
Binary XML file 
line #25: Class not allowed to be inflated 
android.widget.EditText 
E/StatusBar (765): at 
android.view.LayoutInflater. failNotAllowed 
(LayoutInflater.java:695) 
E/StatusBar(765): at 
android.view.LayoutInflater.createView 
(LayoutInflater.java:628) 
E/StatusBar (765): ... 21 more 


上 面 的 异常 信息 很 明确 ，android.widget.EditText 不 允许 在 
RemoteViews 中 使 用 。 


RemoteViews 没 有 0 此 无 法 直接 访问 里 面 
的 View 元 素 ， 而 必须 通过 RemoteViews 所 提供 的 一 系列 set 方 法 来 完 
成 ， 当 然 这 pn ee ae 所 以 没 办 法 直接 
findViewById。 表 5-2 列 举 了 部 分 常用 的 set 方 法 ， 更 多 的 方法 请 查看 相 


5-2 RemoteViews 的 部 分 set 方 法 


A 法 名 E FA 


setTextViewText(int viewId, CharSequence text) 设置 TextView 的 文本 


setTextViewTextSize(int viewld, int units, float size) 设置 TextView 的 字体 大 小 


setTextColor(int viewld, int color) 设置 TextView 的 字体 颜色 


setlmage ViewResource(int viewld, int sreld) 设置 ImageView 的 图 片 资源 


setImageViewResource 设置 ImageView 的 图 片 


setInt(int viewld, String methodName, int value) 反射 调用 View 对 象 的 参数 类 型 为 int 的 方法 


setLong(int viewld, String methodName, long value) 反射 调用 View 对 象 的 参数 类 型 为 long 的 方法 


setBoolean(int viewld, String methodName, boolean value) 反射 调用 View 对 象 的 参数 类 型 为 boolean 的 方法 


setOnClickPendingIntent(int viewld, PendingIntent pendingIntent) | 为 View 添加 单 击 事件 ， 事 件 类 型 只 能 为 PendingIntent 


从 表 5-2 中 可 以 看 出 ， 原 本 可 以 直接 调用 的 View 的 方法 ， 现 在 却 必 
须要 通过 RemoteViews 的 一 系列 set 方 法 才能 完成 ， Dan 
上 来 看 ， 很 像 是 通过 反射 来 完成 的 ， 事 实 上 大 部 分 set 方 法 的 确 是 通 
反射 来 完成 的 。 


下 面 描述 一 下 RemoteViews HY 内 部 机 制 ， 由 于 RemoteViews 主 要 用 
于 通知 柱 和 桌面 小 部 件 之 中 ， 这 里 就 通过 它们 来 分 析 RemoteViews 的 
工作 过 程 。 我 们 知道 ， 通 知 栏 和 桌面 小 部 件 分 别 由 NotificationManager 
Al AppWidgetManager Y # , 而 NotificationManager 和 
AppWidgetManager 通 过 Binder 分 别 和 SystemServer 进程 中 的 
NotificationManagerService 以 及 AppWidgetService 进 行 通 信 。 由 此 可 
见 ， 通 知 栏 和 票面 小 部 件 中 的 布局 文件 实际 上 是 在 
NotificationManagerService 以 中 被 加 载 的 ， 而 它们 
运行 在 系统 的 SystemServer 中 ， 这 融和 我 们 的 进程 构成 了 跨 进 程 通信 
的 场景 。 


首先 RemoteViews 会 通过 Binder 传 递 到 SystemServer 进 程 ， 这 是 
为 RemoteViews 实 现 了 Parcelable 接 口 ， 因 此 它 可 以 跨 进 程 传输 ， 系 统 
会 根据 RemoteViews 中 的 包 名 等 信息 去 得 到 该 应 用 的 资源 。 然 后 会 通 
过 LayoutInflater 去 加 载 RemoteViews 中 的 布局 文件 。 在 SystemServer 进 
程 中 加 载 后 的 布局 文件 是 一 个 普通 的 View， 只 不 过 相对 于 我 们 的 进程 


它 是 一 个 RemoteViews 而 已 。 接 着 系统 会 对 View 执 行 一 系列 界面 更 新 
任务 ， 这 些 任务 束 是 之 前 我 们 通过 set 方 法 来 提交 的 。set 方 法 对 View 所 
做 的 更 新 并 不 是 立刻 执行 的 ， 在 RemoteViews 内 部 会 记录 所 有 的 更 新 
操作 ， 具 体 的 执行 时 机 要 等 到 RemoteViews 被 加 载 以 后 才能 执行 ， 这 
样 RemoteViews 就 可 以 在 SystemServerj 进 程 中 显示 了 ， 这 就 是 我 们 所 看 
到 的 通知 栏 消 恩 或 者 桌面 小 部 件 。 当 需要 更 新 RemoteViews 时 ， 我 们 
需要 调用 一 系列 set 方 法 并 通过 NotificationManager 和 
AppWidgetManager 来 提交 更 新 任务 ， 具 体 的 更 新 探 作 也 是 在 
SystemServer 进 程 中 完成 的 。 


从 理论 上 来 说 ， 系 统 完全 可 以 通过 Binder 去 支持 所 有 的 View 和 
View 探 作 ， 但 是 这 样 做 的 话 代 价 太 大 ， 因 为 View 的 方法 太 多 了 ， 男 外 
就 是 大 量 的 IPC 操 作 会 影响 效率 。 为 了 解决 这 个 问题 ， 系 统 并 没有 通 
过 Binder 去 直接 支持 View 的 跨 进 程 访 问 ， 而 是 提供 了 一 个 Action 的 概 
念 ，Action 代 表 一 个 View 操 作 ，Action 同 样 实 现 了 Parcelable 接 口 。 系 
统 首 先 将 View 控 作 封 狼 到 Action 对 象 并 将 这 些 对 象 跟 进 程 传输 到 远程 
进程 ， 接 着 在 远程 进程 中 执行 Action 对 象 中 的 具体 操作 。 在 我 们 的 应 
用 中 每 调用 一 次 set 方 法 ，RemoteViews 中 束 会 添加 一 个 对 应 的 Action 对 
象 ， 当 我 们 通过 NotificationManager 和 AppWidgetManager 来 捉 交 我 们 
的 更 新 时 ， 这 些 Action 对 象 就 会 传输 到 远程 进程 并 在 远程 进程 中 依次 
执行 ， 这 个 过 程 可 以 参看 图 5-3。 远 程 进 程 通过 RemoteViews 的 apply 方 
法 来 进行 View 的 更 新 操作 ，RemoteViews 的 apply 方 法 内 部 则 会 去 遇 历 
所 有 的 Action 对 象 并 调用 它们 的 apply 方 法 ， 具 体 的 View 更 新 操作 是 由 
Action 对 象 的 apply 方 法 来 完成 的 。 上 述 做 法 的 好 处 是 显而易见 的 ， 首 
先 不 需要 定义 大 量 的 Binder 接 口 ， 其 次 通过 在 远程 进程 中 批量 执行 
RemoteViews 的 修改 操作 从 而 避免 了 大 量 的 IPC 操 作 ， 这 束 提 高 了 程序 
的 性 能 ， 由 此 可 见 ，Android 系 统 在 这 方面 的 设计 的 确 很 精妙 。 


| | 
View 操 作 ———=>! Action | ' Action to es 


Views > Action | Action | Manager 
H> Binder HA 
View 操 作 ———> Action | Action 
RemoteViews RemoteViews 


本 地 进程 | 远程 进程 


图 5-3 RemoteViews 的 内 部 机 制 


上 面 从 理论 上 分 析 了 RemoteViews 的 内 部 机 制 ， 接 下 来 我 们 从 源 
a i a Ee 它 的 构造 方法 就 不 用 多 
说 了 ， 这 里 我 们 首先 看 一 下 它 提 供 的 一 系列 set 方 法 ， 比 如 
setTextViewText 方 法 ， 其 源码 如 下 所 示 。 


public void setTextViewText(int viewId,CharSequence text) { 


setCharSequence(viewlId, "setText", text); 


在 上 面 的 代码 中 ，viewId 是 被 操作 的 View 的 id, “setText”" 是 方法 
名 ，text 是 要 给 TextView 设 置 的 文本 ， 这 里 可 以 联想 一 下 TextView 的 
setText 方 法 ， 是 不 是 很 一 致 呢 ? 接着 再 看 setCharSequence 的 实现 ， 如 
下 所 示 。 


public void setCharSequence(int viewId, String 
methodName, CharSequence 
value) { 


addAction (new 


Ref lectionAction(viewId, methodName, ReflectionAction. 
CHAR_SEQUENCE, value) ); 
} 


从 setCharSequence 的 实现 可 以 看 出 ， 它 的 内 部 并 没有 对 View 进 程 
直接 的 操作 ， 而 是 添加 了 一 个 ReflectionAction 对 象 ， 从 名 字 来 看 ， 这 
应 该 是 一 个 反射 类 型 的 动作 。 再 看 addAction 的 实现 ， 如 下 所 示 。 


private void addAction(Action a) { 


if (mActions == null) { 
mActions = new ArrayList<action>(); 
} 
mActions.add(a); 
// update the memory usage stats 
a.updateMemoryUsageEstimate(mMemoryUsageCounter); 


} 


从 上 有 述 代 码 可 以 知道 ，RemoteViews 内 部 有 一 个 mActions 成 员 ， 它 
是 一 个 ArrayList， 外 界 每 调用 一 次 set 方 法 ，RemoteViews 束 会 为 其 创 
建 一 个 Action 对 象 并 加 入 到 这 个 ArrayList 中 。 需 要 注意 的 是 ， 这 里 仅 
仅 是 将 Action 对 象 保存 起 来 了 ， 并 未 对 View 进 行 实 际 的 操作 ， 这 一 点 
在 上 面 的 理论 分 析 中 已 经 提 到 过 了 。 到 这 里 setTextViewText 这 个 方法 
的 源码 已 经 分 析 完 了 ， 但 是 我 们 好 像 还 是 什么 都 不 知道 的 感觉 ， 没 关 
系 ， 接 着 我 们 需要 看 一 下 这 个 ReflectionAction 的 实现 就 知道 了 。 再 看 
它 的 实现 之 前 ， 我 们 需要 先 看 一 下 RemoteViews 的 apply 方 法 以 及 
Action 类 的 实现 ， 首 先 看 一 下 RemoteViews 的 apply 方 法 ， 如 下 所 示 。 


从 上 面 代码 可 以 看 出 ， 首 先 会 通过 LayoutInflater 去 加 载 
RemoteViews 中 的 布局 文件 ，RemoteViews 中 的 布局 文件 可 以 通过 
getLayoutId 这 个 方法 获得 ， 加 载 完 布局 文件 后 会 通过 performApply 去 
执行 一 些 更 新 操作 ， 代 码 如 下 所 示 。 


private void performApply(View v, ViewGroup 
parent,OnClickHandler handler) { 
if (mActions != null) { 
handler = handler == null ? 
DEFAULT_ON_CLICK_HANDLER : handler; 
final int count = mActions.size(); 
for (int i = 0; i < count; i++) { 
Action a = mActions.get(i); 


a.apply(v,parent,handler); 


N 


performApply 的 实现 就 比较 好 理解 了 ， 它 的 作用 天 是 过 历 
mActions 这 个 列表 并 执行 每 个 Action 对 象 的 apply 方 法 。 还 记得 mAction 
吗 ? 每 一 次 的 set 操 作 都 会 对 应 着 它 里 面 的 一 个 Action 对 象 ， 因 此 我 们 
可 以 断定 ，Action 对 和 象 的 apply 方 法 就 是 真正 操作 View 的 地 方 ， 实 际 上 
的 确 如 此 。 


RemoteViews 在 通知 栏 和 桌面 小 部 件 中 的 工作 过 程 和 上 面 描述 的 
过 程 是 一 致 的 ， 当 我 们 调用 RemoteViews 的 Set 方法 时 ， 并 不 会 立刻 更 
源 它 们 的 界面 ， 而 必须 要 通过 Notification-Manager 的 notify 方 法 以 及 
AppWidgetManager 的 updateAppWidget 才 能 更 新 它们 的 界面 。 实 际 上 在 
AppWidgetManager 的 updateAppWidget 的 内 部 实现 中 ， 它 们 的 确 是 通过 
RemoteViews 的 apply 以 及 reapply 方 法 来 加 载 或 者 更 新 界面 的 ，apply 和 
reApply 的 区 别 在 于 : apply 会 加 载 布 局 并 更 新 界面 ， 而 reApply 则 只 会 
更 新 界面 。 通 知 栏 和 桌面 小 插件 在 初始 化 界面 时 会 调用 apply 方 法 ， 而 


在 后 续 的 更 新 界面 时 则 会 调用 reapply 方 法 。 这 里 先 看 一 下 
BaseStatusBar 的 updateNotificationViews 方 法 中 ， 如 下 所 示 。 


private void updateNotificationViews(NotificationData.Entry 
entry, 
StatusBarNotification notification, boolean 
isHeadsUp) { 
final RemoteViews contentView = 
notification.getNotification(). 
contentView; 


final RemoteViews bigContentView = isHeadsUp 
notification. getNotification().headsUpContentView 


notification. getNotification().bigContentView; 
final Notification publicVersion = 
notification. getNotification().publicVersion; 
final RemoteViews publicContentView = publicVersion != 
null ? public-Version.contentView : null; 


// Reapply the RemoteViews 


contentView. reapply(mContext, entry.expanded, mOnClickHandler ); 


很 显然 ， 上 述 代 码 表 示 当 通知 栏 界 面 需要 更 新 时 ， 它 会 通过 
RemoteViews 的 reapply 方 法 来 更 新 界面 。 


接着 再 看 一 下 AppWidgetHostView 的 updateAppWidget 方 法 ， 在 它 
的 内 部 有 如 下 一 段 代 码 : 


从 上 述 代 码 可 以 发 现 ， 桌 面 小 部 件 在 更 新 界面 时 也 是 通过 
RemoteViews 的 reapply 方 法 来 实现 的 。 


了 解 了 apply 以 及 reapply 的 作用 以 后 ， 我 们 再 继续 看 一 些 Action 的 
子 类 的 具体 实现 ， 首 先 看 一 下 ReflectionAction 的 具体 实现 ， 它 的 源码 
如 下 所 示 。 


通过 上 述 代 码 可 以 发 现 ，ReflectionAction 表 示 的 是 一 个 反射 动 
作 ， 通 过 它 对 View 的 操作 会 以 反射 的 方式 来 调用 ， 其 中 getMethod 残 是 
根据 方法 名 来 得 到 反射 所 需 的 Method 对 象 。 使 用 ReflectionAction 的 set 
方法 有 : setTextViewText、setBoolean、setLong、setDouble 等 。 除 了 
ReflectionAction ， 还 有 其 他 Action ， 比 如 TextViewSizeAction ` 
ViewPaddingAction 、 SetOnClickPendingIntent 等 。 这 里 再 分 析 一 下 
TextViewSizeAction， 它 的 实现 如 下 所 示 。 


TextViewSizeAction 的 实现 比较 简单 ， 它 之 所 以 不 用 反射 来 实现 ， 
是 因为 setTextSize 这 个 方法 有 2 个 参数 ， 因 此 无 法 复 用 
ReflectionAction ， 因 为 ReflectionAction 的 反射 调用 只 有 一 个 参数 。 其 
他 Action 这 里 就 不 一 一 进行 分 析 了 ， 读 者 可 以 查看 RemoteViews 的 源 代 
fg o 


关于 单 击 事件 ，RemoteViews 中 只 文 持 发 起 PendingIntent， 不 文 持 
onClickListener 那 fH E R °> AA, KR Tl HF Be 
setOnClickPendingIntent setPendingIntentTemplate lL 及 
setOnClickFillInIntent E I ZEN K a AK A °° A 
setOnClickPendingIntent 用 于 给 普通 View 设 置 单 击 事件 ， 但 是 不 能 给 集 
A (ListView 和 StackView) 中 的 View 设 置 单 击 事件 ， 比 如 我 们 不 能 给 
ListView 中 的 item 通 过 setOnClickPendingIntent 这 种 方式 添加 单 击 事 
件 ， 因 为 开销 比较 大 ， 所 以 系统 禁止 了 这 种 方式 ; 其次， 如果 要 给 
ListView 和 StackView AY item 添加 单 击 事件 ， 则 必须 将 
setPendingIntentTemplate 和 setOnClickFillInIntent 组 合 使 用 才 可 以 。 


5.3 RemoteViewsHh) MX 


在 5.2 节 中 我 们 分 析 了 RemoteViews 的 内 部 机 制 ， 了 解 RemoteViews 
的 内 部 机 制 可 以 让 我 们 更 加 清楚 通知 栏 和 桌面 小 工具 的 确 层 实现 原 
理 ， 但 是 本 章 对 RemoteViews 的 探索 并 没有 停止 ， 在 本 下 中， 我 们 将 
打造 一 个 模拟 的 通知 栏 效 末 并 实现 跨 进 程 的 UI 更 新 。 


首先 有 2 个 Activity 分 别 运行 在 不 同 的 进程 中 ， 一 个 名 字 叫 A， 男 一 
个 叫 B， 其 中 A 扮演 着 模拟 通知 栏 的 角色 ， 而 B 则 可 以 不 集 地 发 送 通 知 
栏 消 息 ， 当 然 这 是 模拟 的 消息 。 为 了 模拟 通知 栏 的 效果 ， 我 们 修改 A 
的 process 属 性 使 其 运行 在 单独 的 进程 中 ， 这 样 A 和 B 丈 构成 了 多 进程 通 
信 的 情形 。 我 们 在 B 中 创建 RemoteViews 对 象 ， 然 后 通知 A 显示 这 个 
RemoteViews 对 象 。 如 何 通知 A 显 示 B 中 的 RemoteViews 呢 ? 我 们 可 以 
像 系统 一 样 采用 Binder 来 实现 ， 但 是 这 里 为 了 人 简单 起 见 束 采用 了 广 
播 。B 每 发 送 一 次 模拟 通知 ， 束 会 发 送 一 个 特定 的 广播 ， 然 后 A 接收 到 


PTE MAA ARB PE MA RemoteViews Z, ik SUA ASA 
知 栏 消 妃 的 显示 过 程 几乎 一 致 ， 或 者 说 这 里 就 是 复制 了 通知 栏 的 显示 
过 程 而 已 。 


首先 看 B 的 实现 ，B 只 要 构造 RemoteViews 对 象 并 将 其 传输 给 A 即 
可 ， 这 一 过 程 通 知 栏 是 A Binders MA, 但 是 本 例 中 采用 广播 来 实 
现 ，RemoteViews 对 象 通 过 Intent 传 输 到 A 中 ， 代 码 如 下 所 示 。 


RemoteViews remoteViews = new 
RemoteViews(getPackageName(),R.layout.layout_simulated_notifica 
tion); 

remoteViews.setTextViewText(R.id.msg, "msg from process:" + 


Process.myPid()); 


remoteViews.setImageViewResource(R.id.icon,R.drawable.icon1); 
PendingIntent pendingIntent = 
PendingIntent.getActivity(this, 
0, new 
Intent(this, DemoActivity_1.class),PendingIntent.FLAG_UPDATE_CUR 
RENT); 
PendingIntent openActivity2PendingIntent = 
PendingIntent.getActivity( 
this, ©, new 
Intent(this, DemoActivity_2.class),PendingIntent. 
FLAG_UPDATE_CURRENT); 


remoteViews.setOnClickPendingIntent(R.id.item_holder, pendingInt 


A 的 代码 也 很 简单 ， 只 需要 接收 B 中 的 广播 并 显示 RemoteViews 即 
可 ， 如 下 所 示 。 


上 述 代 码 很 简单 ， 除 了 注册 和 解除 广播 以 外 ， 最 主要 的 逻辑 其 实 
瓯 是 updateU[ 方 法 。 当 A 收 到 广播 后 ， 会 从 Intent 中 取出 RemoteViews 对 


象 ， 然 后 通过 它 的 apply 方 法 加 载 布局 文件 并 执行 更 新 操作 ， 最 后 将 得 
到 的 View 添 加 到 A 的 布局 中 即 可 。 可 以 发 现 ， 这 个 过 程 很 簿 单 ， 但 是 
通知 栏 的 展 层 吏 是 这 么 实现 的 。 


本 节 这 个 例子 是 可 以 在 实际 中 使 用 的 ， 比 如 现在 有 两 个 应 用 ， 一 
个 应 用 需要 能 够 更 新 男 一 个 应 用 中 的 某 个 界面 ， 这 个 时 候 我 们 当然 可 
以 选择 AIDL 去 实现 ， 但 是 如 采 对 界面 的 更 新 比较 频繁 ， 这 个 时 候 就 会 
有 效率 问题 ， 同 时 AIDL 接 口 束 有 可 能 会 变 得 很 复杂 。 这 个 时 候 如 有 果 采 
用 RemoteViews 来 实现 就 没有 这 个 问题 了， 当然 RemoteViews 也 有 缺 
点 ， 那 就 是 它 仅 文 持 一 些 常 见 的 View， 对 于 目 定 义 View 它 是 不 文 持 
的 。 面 对 这 种 问题 ， 到 底 是 采用 AIDL 还 是 采用 RemoteViews， 这 个 要 
看 具体 情况 ， 如 果 界 面 中 的 View 都 是 一 些 简单 的 且 被 RemoteViews 文 
FM View, Ob A Al LL 4 EK A RemoteViews, GW Ht Rig & A 


RemoteViews Į 2 


如 果 打 算 采 用 RemoteViews 来 实现 两 个 应 用 之 间 的 界面 更 新 ， 那 
么 这 里 还 有 一 个 问题 ， 那 就 是 布局 文件 的 加 载 问 题 。 在 上 面 的 代码 
中 ， 我 们 直接 通过 RemoteViews 的 apply 方 法 来 加 载 并 更 新 界面 ， 如 下 
所 示 。 


View view = remoteViews.apply(this,mRemoteViewsContent); 


mRemoteViewsContent.addView(view); 


这 种 写法 在 同一 个 应 用 的 多 进程 情形 下 是 适用 的 ， 但 是 如 果 A 和 B 
属于 不 同 应 用 ， 那 么 B 中 的 布局 文件 的 资源 id 传输 到 A 中 以 后 很 有 可 能 
是 无 效 的 ， 因 为 A 中 的 这 个 布局 文件 的 资源 id 不 可 能 刚好 和 B 中 的 资源 
id 一 样 ， 面 对 这 种 情况 ， 我 们 就 要 适当 修改 RemoteViews 的 显示 过 程 的 
代码 了 。 这 里 给 出 一 种 方法 ， 既 然 资 源 id 不 相同 ， 那 我 们 就 通过 资源 


名 称 来 加 载 布 局 文件 。 痢 先 两 个 应 用 要 提前 约定 好 RemoteViews 中 的 
布局 文件 的 资源 名 称 ， 比 如 "layout_simulated_notification”， 然 后 在 A 
中 根据 名 称 查找 到 对 应 的 布局 文件 并 加 载 ， 接 着 再 调用 RemoteViews 
的 reapply 方 法 即 可 将 B 中 对 View 所 做 的 一 系列 更 新 操作 全 部 作用 到 A 中 
加 载 的 View 上 面 。 关 于 apply 和 reapply 方 法 的 差别 在 前 面 已 经 捉 到 过 ， 
这 里 就 不 多 说 了 ， 这 样 整 个 跨 应 用 更 新 界面 的 流程 就 走 通 了 ， 具 体 效 
果 如 图 5-4 所 示 。 可 以 发 现 B 中 的 布局 文件 已 经 成 功 地 在 A 中 显示 了 出 
来 。 修 改 后 的 代码 如 下 : 


int layoutId = 
getResources().getIdentifier("layout_simulated_ 
notification", "layout", getPackageName()); 

View view = 
getLayoutInflater().inflate(layoutId,mRemoteViewsContent, false) 
; 

remoteViews.reapply(this, view); 


mRemoteViewsContent .addView( view) ; 


通知 栏 消息 


发 送 模拟 通知 栏 消息 


msg from process:23056 
open DemoActivity_2 


图 5-4 ”模拟 通知 栏 的 效果 


86% Android JDrawable 


本 章 所 讲述 的 话题 是 Android 的 Drawable，Drawable 表 示 的 是 一 种 
可 以 在 Canvas 上 进行 绘制 的 抽象 的 概念 ， 它 的 种 类 有 很 多 ， 最 常见 的 
颜色 和 图 片 都 可 以 是 一 个 Drawable°。 在 本 半 中 ， 首 先 描述 Drawable 的 
层次 关系 ， 接 着 介绍 Drawable 的 分 类 ， 最 后 介绍 目 定 义 Drawable 相 关 
的 知识 。 本 章 的 内 容 看 起 来 稍微 有 点 简单 ， 但 是 由 于 Drawable 的 种 类 
比较 党 多 ， 从 而 导致 了 开发 者 对 不 同 Drawable 的 理解 比较 混乱 。 另 外 
一 点 ， 熟 练 掌握 各 种 类 型 的 Drawable 可 以 方便 我 们 做 出 一 些 特殊 的 UI 
效果 ， 这 一 点 在 UI 相关 的 开发 工作 中 尤其 重要 。Drawable 在 开发 中 有 
着 目 己 的 优点 : 首先 ， 它 使 用 简单 ， 比 目 定义 View 的 成 本 要 低 ; 其 
次 ， 非 图 片 类 型 的 Drawable 占 用 空间 较 小 ， 这 对 减 小 apk 的 大 小 也 很 有 
帮助 。 鉴 于 上 述 两 点 ， 全 面 理解 Drawable 的 使 用 细节 还 是 很 有 必要 
的 ， 这 也 是 本 章 的 出 发 点 。 


6.1 Drawable 人 简介 


Drawable 有 很 多 种 ， 它 们 都 表示 一 种 图 像 的 概念 ， 但 是 它们 又 不 
全 是 图 片 ， 通 过 颜色 也 可 以 构造 出 各 式 各 样 的 图 像 的 效果 。 在 实际 开 
发 中 ，Drawable 常 彼 用 来 作为 View 的 背景 使 用 。Drawable 一 般 都 是 通 
过 XML 来 定义 的 ， 当 然 我 们 也 可 以 通过 代码 来 创建 具体 的 Drawable 对 
象 ， 只 是 用 代码 创建 会 稍 显 复杂 。 在 Android 的 设计 中 ，Drawable 是 一 
个 抽象 类 ， 它 是 所 有 Drawable 对 象 的 基 类 ， 每 个 具体 的 Drawable 都 是 


EMF, HANShapeDrawable ` BitmapDrawable%*, Drawablef Ei 
关系 如 图 6-1 所 示 。 


4 © Object - java.lang 
a ^ Drawable - android.graphics.drawa 
A ' 


BitmapDrawable - android.graphics.drawable 
ClipDrawable - android.graphics.drawable 
ColorDrawable - android.graphics.dra 
DrawableContainer - android.graphics.drawable 
© AnimationDrawable - android.graphics.dra 
© LevellistDrawable - android.graphics.dr: 

4 © StatelistDrawable - android.graphics.drawab 

© AnimatedStatelistDrawable - android.graphics.drawable 

GradientDrawable - android.graphics.drawable 
InsetDrawable - : ap! 
InsetDrawable - android.graphics.drawable 
Q SlideDrawable - android.support.v4.app.ActionBarDrawerToggle 
LayerDrawable - android.graphics.drawable 
© RippleDrawable - android.graphics.drawable 
© TransitionDrawable - android.graphics.drawable 
NinePatchDrawable - android.graphics.draw 
PictureDrawable - android.graphics.drawable 
RotateDrawable - android.graphics.drawable 
ScaleDrawable - android.graphics.drawable 
ShapeDrawable - android.graphics.drawable 
© PaintDrawable - android.graphics.drawable 
VectorDrawable - android.graphics.drawable 


图 6-1 Drawable 的 层次 关系 


Drawable 的 内 部 加 /高 这 个 参数 比较 重要 ， 通 过 getIntrinsicWidth 和 
getIntrinsicHeight 这 两 个 方法 可 以 获取 到 它 f 。 但 是 并 不 是 所 有 的 
Drawable 都 有 内 部 宽 / 高 ， 比 如 一 张 图 片 所 形成 的 Drawable， 它 的 内 部 
宽 / 高 就 是 图 片 的 宽 /高 ， 但 是 一 个 颜色 所 形成 的 Drawable， 它 束 没 有 内 
部 宽 / 高 的 概念 。 另 外 需要 注意 的 是 ，Drawable 的 内 部 宽 / 高 不 等 同 于 它 
的 大 小 ， 一 般 来 说 ，Drawable 是 没有 大 小 概念 的 ， 当 用 作 View 的 背景 
时 ，Drawable 会 被 拉 伸 至 View 的 同等 大 小 。 


6.2 ”Drawable 的 分 类 


Drawable NH X 2 , % MW EN @ BitmapDrawable ` 
ShapeDrawable ` LayerDrawable LX StateListDrawable®, ix Bat — 
ER ZA EINE ° 


6.2.1 BitmapDrawable 


这 几乎 是 最 简单 的 Drawable T, “EAH RRA e ER 
开发 中 ， 我 们 可 以 直接 引用 原始 的 图 片 即 可 ,但 是 也 可 以 通过 XML 的 
方式 来 描述 它 ， 通 过 XML 来 描述 的 BitmapDrawable 可 以 设置 更 多 的 效 
果 ， 如 下 所 示 : 


<?xml version="1.0" encoding="utf-8"?> 


<bitmap 


xmins:android="http://schemas.android.com/apk/res/android" 
android: src="@[package: ]drawable/drawable_resource" 
android:antialias=["true" | "false"] 
android:dither=["true" | "false"] 
android: filter=["true" | "false"] 
android:gravity=["top" | "bottom"|"left"|"right" | 
"center_vertical" | 
"fill vertical"|"center_horizontal" 
| "fill_horizontal" | 


"center" | "fill" | "clip_vertical" 


| "clip_horizontal"] 
android:mipMap=["true" | "false"] 


android:tileMode=["disabled" 


"clamp" | "repeat" | 


"mirror"] /> 
FREES NBA ° 
android:src 
ISRA, DEBA Aid 。 
android:antialias 


古人 否 开局 图 片 抗 锯 众 功能。 开启 后 会 让 图 片 变 得 平滑 ， 同 时 也 会 
在 一 定 程 度 上 降低 图 片 的 清晰 度 ， 但 是 这 个 降低 的 幅度 较 低 以 至 于 可 
以 忽略 ， 因 此 抗 饥 资 选项 应 该 开局 。 


android:dither 


是 否 开启 拌 动 效果 。 当 图 片 的 像素 配置 和 手机 屏幕 的 像素 配置 不 
一 致 时 ， 开 启 这 个 选项 可 以 让 高 质量 的 图 片 在 低 质量 的 屏幕 上 还 能 保 
持 较 好 的 显示 效果 ， 比 如 图 片 的 色彩 模式 为 ARGB8888， 但 是 设备 屏 
幕 所 支持 的 色彩 模式 为 RGB555， 这 个 时 候 开 启 拌 动 选 项 可 以 让 图 片 
显示 不 会 过 于 失真 。 在 Android 中 创建 的 Bitmap 一 般 会 选用 ARGB8888 
这 个 模式 ， 即 ARGB 四 个 通道 各 占 8 位 ， 在 这 种 色彩 模式 下 ， 一 个 像素 
所 占 的 大 小 为 4 个 字 节 ， 一 个 像素 的 位 数 总 和 越 高 ， 图 像 也 就 越 逼 真 。 
根据 分 析 ， 拌 动 效 果 也 应 该 开启 。 


android:filter 


征 否 开局 过 滤 效 打 。 当 图 片 太 才 被 拉 伸 或 者 压缩 时 ， 开 局 过 滤 效 
果 可 以 保持 较 好 的 显示 效果 ， 因 此 此 选项 也 应 该 开局 。 


android:gravity 


当 图 片 小 于 容器 的 尺寸 时 ， 设 置 此 选项 可 以 对 图 片 进行 定位 。 这 
个 属性 的 可 选项 比较 多 ， 不 同 的 选项 可 以 通过 “" 来 组 合 使 用 ， 如 表 6-1 
PASS 


表 6-1 ”gravity 属 性 的 可 选项 


可 选项 含 x 
bes 将 图 片 放 在 容器 的 顶部 ， 不 改变 图 片 的 大 小 
将 图 片 放 在 容器 的 底部 ， 不 改变 图 片 的 大 小 
left 将 图 片 放 在 容器 的 左 部 ， 不 改变 图 片 的 大 小 
right 将 图 片 放 在 容器 的 右 部 ， 不 改变 图 片 的 大 小 


center_vertical 更 图 片 竖 直 居 中 ， 不 改变 图 片 的 大 小 


fill_ vertical | RS EL Ay ld AA 


center_horizontal 更 图 片 水 平 居中 ， 不 改变 图 片 的 大 小 
fill_horizontal ARE Aa Wl AR 
center 更 图 片 在 水 平和 竖 直 方向 同时 居中 ， 不 改变 图 片 的 大 小 
fill 图 片 在 水 平和 竖 直 方向 均 填 充 容器 ， 这 是 默认 值 


clip_vertical 附加 选项 ， 表 示 竖 直方 向 的 裁剪 ， 较 少 使 用 


附加 选项 ， 表 示 水 平方 向 的 裁 前 ， 较 少 使 用 


android:mipMap 


这 是 一 种 图 像 相 关 的 处 理 技术 ， 也 叫 纹理 映射 ， 比 较 抽 和 象 ， 这 里 
也 不 对 其 深究 了 ， 默 认 值 为 false， 在 日 常 开 发 中 此 选项 不 常用 。 


android:tileMode 


平 铺 模式 。 这 个 选项 有 如 下 儿 个 值 
["disabled"|"clamp"|"repeat"|"mirror"], HH disable KA F TRIN, 
这 也 是 默认 值 ， 当 开局 平 铺 模 式 后 ，gravity 属 性 会 被 忽略 。 这 里 主要 


说 一 下 repeat、miror 和 clamp 的 区 别 ， 这 三 者 都 表示 平 铺 模 式 ， 但 是 它 
们 的 表现 却 有 很 大 不 同 。repeat 表 示 的 是 简单 的 水 平和 竖 直 方 同 上 的 平 
HAR; mirror 表 示 一 种 在 水 平和 竖 直 方向 上 的 镜面 投影 效果 ; 而 
clamp 表 示 的 效果 束 更 加 奇特 ， 图 片 四 周 的 像素 会 扩展 到 周围 区 域 。 下 
面 我 们 看 一 下 这 三 者 的 实际 效果 ， 通 过 实际 效果 可 以 更 好 地 理解 不 同 
的 平 铺 模式 的 区 别 ， 如 图 6-2 所 示 。 
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(1) repeat (2) mirror (3) clamp 


图 6-2 平 铺 模式 下 的 图 片 显 示 效 果 


接 下 来 介绍 NinePatchDrawable ， 它 表示 的 是 一 张 .9 格式 的 
上 户 ，.9 图 片 可 以 目 动 地 根据 所 需 的 宽 / 高 进行 相应 的 缩放 并 保证 不 失 
真 ， 之 所 以 把 它 和 BitmapDrawable 放 在 一 起 介绍 是 因为 它们 都 表示 一 
张 图 片 。 和 BitmapDrawable 一 样 ， 在 实际 使 用 中 直接 引用 图 片 即 可 ， 
但 是 也 可 以 通过 XML 来 描述 .9 图 ， 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<nine-patch 


xmlns:android="http://schemas.android.com/apk/res/android" 
android: src="@[package: ]drawable/drawable_resource" 


android:dither=["true" | "false"] /> 


上 述 XML 中 的 属性 的 含义 和 BitmapDrawable 中 的 对 应 属性 的 含义 
是 相同 的 ， 这 里 束 不 再 描述 了 ， 男 外 ， 在 实际 使 用 中 发 现在 bitmap 标 
签 中 也 可 以 使 用 .9 图 ， 即 BitmapDrawable 也 可 以 代表 一 个 .9 格式 的 图 
片 。 


6.2.2 ShapeDrawable 


ShapeDrawable 是 一 种 很 常见 的 Drawable， 可 以 理解 为 通过 颜色 来 
构造 的 图 形 ， 它 既 可 以 是 纯色 的 图 形 ， 也 可 以 是 具有 渐变 效果 的 
形 。ShapeDrawable 的 语法 稍 显 复杂 ， 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<shape 


xmins:android="http://schemas.android.com/apk/res/android" 


android:shape=["rectangle" | "oval" | "line" | "ring"] 


<corners 
android: radius="integer" 
android: topLeftRadius="integer" 
android: topRightRadius="integer" 
android: bottomLeftRadius="integer" 
android: bottomRightRadius="integer" /> 
<gradient 
android: angle="integer" 


android: centerX="integer" 


需要 注意 的 是 <shape> 标 签 创 建 的 Drawable， 其 实体 类 实际 上 是 
GradientDrawable， 下 面 分 别 介绍 各 个 属性 的 含义 。 


android:shape 


表示 图 形 的 形状 ， 有 四 个 选项 : rectangle (Æ) > oval fi 
Bl) > line 〈 横 线 ) Fring (HH) 。 它 的 默认 值 是 和 矩形， 另外 line 和 
ring 这 两 个 选项 必须 要 通过 <stroke> 标 签 来 指定 线 的 宽度 和 颜色 等 信 
上 息 ， 否 则 将 无 法 达到 预期 的 显示 效果 。 


针对 ring 这 个 形状 ， 有 5 个 特殊 的 属性 : android:innerRadius ` 
android:thickness ` android:innerRadiusRatio 、 android:thicknessRatio 和 
android:useLevel， 它 们 的 含义 如 表 6-2 所 示 。 


62 ring 的 属性 值 


pay) 


Value Desciption 


android:innerRadius 圆 环 的 内 半径 ， 和 android:innerRadiusRatio 同时 存在 时 ， 以 android:innerRadius 为 准 
android:thickness 圆 环 的 厚度 ， 即 外 半径 减 去 内 半径 的 大 小 ， 和 android:thicknessRatio 同时 存在 时 ， 以 


android:thickness 为 准 


android:innerRadiusRatio 内 半径 占 整 个 Drawable 宽度 的 比例 ， 默 认 值 为 9。 如 果 为 nb， 那么 内 半径 = 宽度 /n 


android:thicknessRatio 厚度 占 整 个 Drawable 宽度 的 比例 ， 默 认 值 为 3。 如果 为 n， 那 么 厚度 = 宽度 /n 


android:useLevel - 般 都 应 该 使 用 false, 否则 有 可 能 无 法 到 达 预 期 的 显示 效果 , 除非 它 被 当 作 LevelListDrawable 
来 使 用 


<corners> 


#2 7NshapeH) VU +A AIRE >: ERE TP shape, AREA E 
是 指 圆 角 的 程度 ， 用 px 来 表示 ， 它 有 如 下 5 个 属性 : 


e android:radius 为 四 个 角 同 时 设 定 相同 的 角度 ， 优 先 级 较 低 ， 
会 被 其 他 四 个 属性 覆盖 

。 android:topLeftRadius 一 一 设 定 最 上 角 的 角度 ; 

。 android:topRightRadius 一 一 设 定 右 上 角 的 角度 ; 

e android:bottomLeftRadius 一 一 设 定 最 下 角 的 角度 ; 


android:bottomRightRadius 一 -一 设 定 右 下 角 的 角度 > 


<gradient> 


ES ssolid> Mé ARRE JR, solide an 48 BR ot, Mm 


gradient 则 表示 渐变 效果 ，gradient 有 如 下 几 个 属性 : 


android:angle 渐变 的 角度 ， 默 认为 0， 其 值 必须 为 45 的 倍数 ，0 
表示 从 左 到 右 ，90 表 示 从 下 到 上 ， 具 体 的 效果 需要 目 行 体验 ， 总 
之 角度 会 影响 渐变 的 方 问 ; 

渐变 的 中 心 点 的 横 坐 标 ; 

渐变 的 中 心 点 的 纵 坐 标 ， 渐 变 的 中 心 点 会 影响 


android:centerX 


android:center Y 


渐变 的 具体 效 采 ; 


android:startColor 渐变 的 起 始 色 
android:centerColor 渐变 的 中 间 色 ; 
android:endColo 渐变 的 结束 色 


android:gradientRadius 渐变 半径 ， 仅 当 android:type= "radial" FY 
有 效 ; 
android:useLevel — fit 为 false , 当 Drawable 作为 
StateListDrawable 使 用 时 为 true; 

android:type 一 一 渐变 的 类 别 ， 有 linear (线性 渐变 ) > radial (14 
向 渐变 ) 、sweep (扫描 线 渐变 ) 三 种 ， 其 中 默认 值 为 线性 渐变 ， 
它们 三 者 的 区 别 如 图 6-3 所 示 。 


图 6-3 ”渐变 的 类 别 ， 从 左 到 右 依次 为 linear > radial > sweep 


<solid> 


这 个 标签 表示 纯色 填充 ， 通 过 android:color 即 可 指定 shape 中 填充 
的 颜色 > 


<stroke> 
Shape 的 撒 边 ， 有 如 下 几 个 属性 : 


android:width- 一 描 边 的 宽度 ， 越 大 则 shape 的 边缘 线 驶 会 看 起 来 
越 粗 ; 

android:color MINE; 

android:dashWidth 一 一 组 成 虚线 的 线段 的 宽度 ; 

android:dashGap 一 一 组 成 虚线 的 线段 之 则 的 间隔 ， 间 隔 越 大 则 虚 
线 看 起 来 空隙 就 越 大 。 


注意 如 果 android:dashWidth 和 android:dashGap 有 任何 一 个 为 0， 那 
么 虚线 效果 将 不 能 生效 。 下 面 是 一 个 具体 的 例子 ， 效 采 图 如 图 6-4 所 
不 o 


图 6-4 ”shape 的 描 边 效果 


<?xml version="1.0" encoding="utf-8"?> 
<shape 
xm1ns:android="http://schemas.android.com/apk/res/android" 
android:shape="rectangle" > 
<solid android:color="#ff0000" /> 
<stroke 
android:dashGap="2dp" 
android:dashwidth="10dp" 
android:width="2dp" 
android:color="#00ff00" /> 


</shape> 


<padding> 


这 个 表示 空 日 ,但 是 它 表示 的 不 是 shape 的 空 日 ， 而 是 包含 它 的 
View 的 空 日 ， 有 四 个 属性 : android:left、android:top、android:right 和 


android:bottom ° 
<size> 


shape 的 大 小 ， 有 两 个 属性 : android:width 和 android:height， 分 别 
表示 shape 的 宽 / 高 。 这 个 表示 的 是 shape 的 固有 大 小 ， 但 是 一 般 来 说 它 
并 不 是 shape 最 终 显示 的 大 小 ， 这 个 有 点 抽象 ， 但 是 我 们 要 明日 ， 对 于 
shape 来 说 它 并 没有 宽 / 高 的 概念 ， 作 为 View 的 背景 它 会 目 适 应 View 的 
宽 / 高 。 我 们 知道 Drawable 的 两 个 方法 getmtrinsicWidth 和 
getImtrinsicHeight 表 示 的 是 Drawable 的 固有 宽 / 高 ， 对 于 有 些 Drawable 比 
如 图 上 来 说 ， 它 的 固有 宽 / 高 就 是 图 片 的 尺寸 。 而 对 于 shape 来 说 ， 默 
认 情 况 下 它 是 没有 固有 视 / 高 这 个 概念 的 ， 这 个 时 候 getIntrinsicWidth 和 
getIntrinsicHeight 会 返回 -1， 但 是 如 果 通 过 <size> 标 签 来 指定 宽 / 高 信 
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<Ssize> 标 签 设 置 的 宽 / 高 就 是 ShapeDrawable 的 固有 宽 / 高 ， 但 是 作为 
View 的 背景 时 ，shape 还 会 被 拉 伸 或 者 缩小 为 View 的 大 小 。 


6.2.3 LayerDrawable 


LayerDrawable 对 应 的 XML 标 签 是 <layer-list>， 它 表示 一 种 层次 化 
的 Drawable 集 合 ， 通 过 将 不 同 的 Drawable 放 置 在 不 同 的 层 上 面 从 而 达 
到 一 种 个 加 后 的 效果 。 它 的 语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<layer - list 


xmins:android="http://schemas.android.com/apk/res/android"> 


<item 


android: drawable="@[ package: ]drawable/drawable_resource" 
android: id="@[+][package: Jid/resource_name" 
android: top="dimension" 
android: right="dimension" 
android: bottom="dimension" 
android: left="dimension" /> 


</layer-list> 


一 个 layer-list 中 可 以 包含 多 个 item， 每 个 item 表 示 一 个 Drawable 。 
Item 的 结构 也 比较 简单， 比较 常用 的 属性 有 android:top ` 
android:bottom 、android:left 和 android:right， 它 们 分 别 表 示 Drawable 相 
对 于 View 的 上 下 左右 的 偏 移 量 ， 单 位 为 像素 。 男 外 ， 我 们 可 以 通过 
android:drawable 属 性 来 直接 引用 一 个 已 有 的 Drawable 资 源 ， 也 可 以 在 
item 中 目 定 义 Drawable。 默 认 情 况 下 ，layer-list 中 的 所 有 的 Drawable 都 
会 被 缩放 至 View 的 大 小 ， 对 于 bitmap 来 说 ， 需 要 使 用 android:gravity 属 
性 才能 控制 图 厂 J 显示 效果 。Layer-list 有 层次 的 概念 ， 下 面 的 item 会 
禾 盖 上 面 的 item， 通 过 合理 的 分 层 ， 可 以 实现 一 些 特殊 的 车 加 效果 。 


下 面 是 一 个 layer-list 具 体 使 用 的 例子 ， 它 实现 了 微 信 中 的 文本 输入 
框 的 效果 ， 如 图 6-5 所 示 。 当 然 它 只 适用 于 日 色 背 景 上 的 文本 输入 框 ， 
另外 这 种 效果 也 可 以 采用 .9 图 来 实现 。 
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图 6-5 layerlist 的 应 用 


6.2.4 StateListDrawable 


StateListDrawable 对 应 于 <selector> 标 签 ， 它 也 是 表示 Drawable 集 
合 ， 每 个 Drawable 都 对 应 着 View 的 一 种 状态 ， 这 样 系 统 就 会 根据 View 
的 状态 来 选择 合适 的 Drawable 。StateListDrawable 主 要 用 于 设置 可 单 击 


的 View 的 育 景 ， 最 稼 见 的 是 Button， 这 个 读者 应 该 不 阳 生 ， 它 的 语法 


如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<selector 


xmlns:android="http://schemas.android.com/apk/res/android" 


android:constantSize=["true" | "false"] 
android:dither=["true" | "false"] 
android:variablePadding=["true" | "false"] > 
<item 


android: drawable="@[ package: ]drawable/drawable_resource" 


android: 
android: 
android: 
android: 
android: 
android: 
android: 
android: 


android: 


</selector> 


针对 上 面 的 语法 ， 


state_pressed=["true" | "false"] 
state_focused=["true" | "false"] 
state_hovered=["true" | "false" ] 
state_selected=["true" | "false"] 
state_checkable=["true" | "false"] 
state_checked=["true" | "false" ] 
state_enabled=["true" | "false" ] 
state_activated=["true" | "false"] 
state_window_focused=["true" | "false"] /> 
下 面 做 简单 介绍 。 


android:constantSize 


StateListDrawable 的 固有 大 小 是 否 不 随 着 其 状态 的 改变 而 改变 的 ， 
为 状态 的 改变 会 导致 StateListDrawable 切 换 到 具体 的 Drawable， 而 不 
同 的 Drawable 具 有 不 同 的 固有 大 小 。True 表 示 StateListDrawable 的 固有 
大 小 保持 不 变 ， 这 时 它 的 固有 大 小 是 内 部 所 有 Drawable 的 固有 大 小 的 
最 大 值 ，false 则 会 随 着 状态 的 改变 而 改变 。 此 选项 默认 值 为 false 。 


android:dither 


是 否 开启 拌 动 效果 ， 这 个 在 BitmapDrawable 中 也 有 提 人 到， 开局 此 
选项 可 以 让 图 片 在 低 质 量 的 屏幕 上 仍然 获得 较 好 的 显示 效果 。 此 选项 
默认 值 为 tue。 


android:variablePadding 


StateListDrawable 的 padding 表 示 是 否 随 着 其 状态 的 改变 而 改变 ， 
true 表 示 会 随 着 状态 的 改变 而 改变 ，false 表 示 StateListDrawable 的 
padding 是 内 部 所 有 Drawable 的 padding 的 最 大 值 。 此 选项 默认 值 为 
false， 并 且 不 建议 开局 此 选项 。 


<item> 标 签 表 示 一 个 具体 的 Drawable， 它 的 结构 也 比较 简单， 其 
中 android:drawable 是 一 个 已 有 Drawable 的 资源 id， 剩 下 的 属性 表示 的 
是 View 的 各 种 状态 ， 每 个 item 表 示 的 都 是 一 种 状态 下 的 Drawable 信 
轧 。View 的 间 见 状态 如 表 6-3 所 示 。 


表 6-3 View 的 常见 状态 


android:state_pressed 


android:state_focused 


android:state_selected 表示 用 户 选择 了 View 


android:state_checked 表示 用 户 选 中 了 View， 一 般 适用 于 CheckBox 这 类 在 选中 和 非 选中 状态 之 间 进 行 切换 的 View 


android:state_enabled 表示 View 当前 处 于 可 用 状态 


下 面 给 出 具体 的 例子 ， 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<selector 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:state_pressed="true" 
android:drawable="@drawable/button_pressed" /> 
<!--pressed --> 
<item android:state_focused="true" 
android: drawable="@drawable/button_focused" /> 
<!--focused --> 
<item android: drawable="@drawable/button_normal" /> 
<!--default --> 


</selector> 


系统 会 根据 View 当 前 的 状态 从 selector 中 选择 对 应 的 item， 每 个 
item 对 应 着 一 个 具体 的 Drawable， 系 统 按照 从 上 到 下 的 顺序 查找 ， 直 
至 查找 到 第 一 条 匹配 的 item。 一 般 来 说 ， 默 认 的 item 都 应 该 放 在 
selector 的 最 后 一 条 并 且 不 附带 任何 的 状态 ， 这 样 当 上 面 的 item 都 无 法 
匹配 View 的 当前 状态 时 ， 系 统 驶 会 选择 默认 的 item， 因 为 默认 的 item 
不 附带 状态 ， 所 以 它 可 以 匹配 View 的 任何 状态 。 


6.2.5 LevelListDrawable 


LevelListDrawable 对 应 于 <level-list> 标签 ， 它 同样 表示 一 个 
Drawable 集 合 ， 集 合 中 的 每 个 Drawable 都 有 一 个 等 级 (level) 的 概 
念 。 根 据 不 同 的 等 级 ，LevelListDrawable 会 切换 A 对 应 的 Drawable， 

它 的 语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<level-list 


xmlns:android="http://schemas.android.com/apk/res/android" > 
<item 
android: drawable="@drawable/drawable_resource" 
android: maxLevel="integer" 
android:minLevel="integer" /> 


</level-list> 


上 面 的 语法 中 ， 每 个 item 表 示 一 个 Drawable， 并 且 有 对 应 的 等 级 
范围 ， 由 android:min-Level 和 android:maxLevel 来 指定 ， 在 最 小 值 和 最 
大 值 之 间 的 等 级 会 对 应 此 item 中 Rank 。 下 面 是 一 个 实际 的 例 
子 ， 当 它 作 为 View 的 背景 时 ， 可 以 通过 Drawable 的 setLevel 方 法 来 设置 
不 同 的 等 级 从 而 切换 具体 的 Drawable。 如 果 它 被 用 来 作为 InageView 的 
前 景 Drawable， 那 么 还 可 以 通过 ImageView 的 setImageLevel 方 法 来 切换 
Drawable。 最 后 ，Drawable 的 等 级 是 有 范围 的 ， 即 0 一 10000， 最 小 等 
级 是 0(， 这 也 是 默认 值 ， 最 大 等 级 是 10000。 


6.2.6 TransitionDrawable 


TransitionDrawable 对 应 于 <transition> 标签， 它 用 于 实现 两 个 
Drawable 之 间 的 淡 入 淡出 效果 ， 它 的 语法 如 下 所 示 。 


android:bottom="dimension" 
android:left="dimension" /> 


</transition> 


上 面 语 法 中 的 属性 前 面 已 经 都 介绍 过 了 ， 其 中 android:top ` 
android:bottom、android:left 和 android:right 仍 然 表 示 的 是 Drawable 四 有 局 
的 偏 移 量 ， 这 里 惑 不 多 介绍 了 了 人。 下面 给 出 一 个 实际 的 例子 。 


首先 定义 TransitionDrawable， 如 下 所 示 。 


// res/drawable/transition_drawable.xml 
<?xml version="1.0" encoding="utf-8"?> 
<transition 
xmins:android="http://schemas.android.com/apk/res/android"> 
<item android: drawable="@drawable/drawable1i" /> 
<item android: drawable="@drawable/drawable2" /> 


</transition> 


接着 将 上 面 的 TransitionDrawable 设 置 为 View 的 背景 ， 如 下 所 示 。 
当然 也 可 以 在 ImageView 中 直接 作为 Drawable 来 使 用 。 


<TextView 
android:id="@+id/button" 
android:layout_height="wrap_content" 
android:layout_width="wrap_content" 


android:background="@drawable/transition_drawable" /> 


最 后 ， 通 过 它 的 startTransition 和 reverseTransition 方 法 来 实现 淡 入 
淡出 的 效果 以 及 它 的 逆 过 程 ， 如 下 所 示 。 


TextView textView = (TextView) 
findViewById(R.id.test_transition); 
TransitionDrawable drawable = (TransitionDrawable) 
textView.getBackground(); 


drawable.startTransition(1000); 


6.2.7 InsetDrawable 


InsetDrawable Xf Y <inset> HZ, EA LAE EL {tt Drawable A Ek Ell 
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景 比 上 自己 的 实际 区 域 小 的 时 候 ， 可 以 采用 InsetDrawable 来 实现 ， 同 时 
我 们 知道 ， 通 过 LayerDrawable 也 可 以 实现 这 种 效果 。InsetDrawable 的 
语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<inset 


xmins:android="http://schemas.android.com/apk/res/android" 
android: drawable="@drawable/drawable_resource" 
android: insetTop="dimension" 
android: insetRight="dimension" 
android: insetBottom="dimension" 


android: insetLeft="dimension" /> 


上 面 的 属性 都 比较 好 理解 ， 其 中 android:insetTop ` 
android:insetBottom 、android:insetLeft 和 android:insetRight 分 别 表 示 顶 


Hb. Jabs ARMADA MITA ° E NETA A, inset shape 
距离 View 的 边界 为 15dp。 


<?xml version="1.0" encoding="utf-8"?> 
<inset 
xmins:android="http://schemas.android.com/apk/res/android" 
android: insetBottom="15dp" 
android: insetLeft="15dp" 
android: insetRight="15dp" 
android:insetTop="15dp" > 
<shape android:shape="rectangle" > 
<solid android:color="#ff0000" /> 
</shape> 


</inset> 


6.2.8 ScaleDrawable 


ScaleDrawable 对 应 于 <scale> 标 签 ， 它 可 以 根据 目 己 的 等 级 
(level) 将 指定 的 Drawable 缩 放 到 一 定 比 例 ， 它 的 语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<scale 


xmins:android="http://schemas.android.com/apk/res/android" 
android: drawable="@drawable/drawable_resource" 
android:scaleGravity=["top" | "bottom" | "left" | 


"right" | "center_ 


vertical" |"fill vertical" | "center_horizontal" | 
MPL Orizonte" | center. A CN ette al | 
"clip_horizontal"] 
android:scaleHeight="percentage" 


android:scalewidth="percentage" /> 


在 上 面 的 属性 中 ，android:scaleGravity 的 含义 等 同 于 shape 中 的 
android:gravity， 而 android:scaleWidth 和 android:scaleHeight 分 别 表示 对 
指定 Drawable 宽 和 高 的 缩放 比例 ， 以 百分比 的 形式 表示 ， 比 如 252 。 


ScaleDrawable 有 点 费解 ， 要 理解 它 ， 我 们 冲 移 要 明日 等 级 对 
ScaleDrawable 的 影响 。 等 级 0 表示 ScaleDrawable 不 可 见 ， 这 是 默认 
值 ， 要 想 ScaleDrawable 可 见 ， 需 要 等 级 不 能 为 0， 这 一 点 从 源码 中 可 
以 得 出 。 来 看 一 下 ScaleDrawable 的 draw 方 法 ， 如 下 所 示 。 


public void draw(Canvas canvas) { 
if (mScaleState.mDrawable.getLevel() != 0) 
mScaleState.mDrawable.draw(canvas); 


} 


很 显然 ， 由 于 ScaleDrawable 的 等 级 和 mDrawable 的 等 级 是 保持 一 
致 的 ， 所 以 如 果 ScaleDrawable 的 等 级 为 0， 那 么 它 内 部 的 mDrawable 的 
等 级 也 必然 为 0， 这 时 mpDrawable 束 无 法 绘制 出 来 ， 也 就 是 
ScaleDrawable 不 可 见 。 下 面 再 看 一 下 ScaleDrawable 的 onBoundsChange 
方法 ， 如 下 所 示 。 


protected void onBoundsChange(Rect bounds) { 


final Rect r = mTmpRect; 


在 ScaleDrawable 的 onBoundsChange 方 法 中 ， 我 们 可 以 看 出 
mDrawable 的 大 小 和 等 级 以 及 缩放 比例 的 关系 ， 这 里 拿 宽 度 来 说 ， 如 
下 所 示 。 


final int iw = min 2 
mScaleState.mDrawable.getIntrinsicWidth() : 0; 
w -= (int) ((w -iw) * (10000 -level) i 
mScaleState.mScalewidth / 10000); 


由 于 iw 一 般 都 为 0， 所 以 上 面 的 代码 可 以 简化 为 : w -= (int) (w * 
(10000 -level) * mScaleState.mScaleWidth / 10000)。 由 此 可 见 ， 如 果 
ScaleDrawable 的 级 别 为 最 大 值 10000， 那 么 就 没有 缩放 的 效果 ;如果 
ScaleDrawable 的 级 别 (level) 越 大 ， 那 么 内 部 的 Drawable 看 起 来 瓯 越 
X; 如 采 ScaleDrawable 的 XML 中 所 定义 的 缩放 比例 越 大 ， 那 么 内 部 的 
Drawable 看 起 来 承 越 小 。 另 外 ， 从 ScaleDrawable 的 内 部 实现 来 看 ， 
ScaleDrawable 的 作用 更 偏向 于 缩小 一 个 特定 的 Drawable。 在 下 面 的 例 
子 中 ， 可 以 近似 地 将 一 张 图 片 缩小 为 原 大 小 的 30%， 代 码 如 下 所 示 。 


// res/drawable/scale_drawable.xml 
<?xml version="1.0" encoding="utf-8"?> 
<scale 
xmins:android="http://schemas.android.com/apk/res/android" 
android: drawable="@drawable/image1" 
android: scaleHeight="70%" 
android: scalewidth="70%" 


android:scaleGravity="center" /> 


直接 使 用 上 面 的 drawable 资 源 是 不 行 的 ， 还 必须 设置 
ScaleDrawable 的 等 级 为 大 于 0 且 小 于 等 于 10000 的 值 ， 如 下 所 示 。 


View testScale = findViewById(R.id.test_scale); 
ScaleDrawable testScaleDrawable = (ScaleDrawable) 
testScale.getBackground(); 


testScaleDrawable.setLevel(1); 


经 过 上 面 的 两 步 可 以 正确 地 缩放 一 个 Drawable， 如 果 少 了 设置 等 
级 这 一 步 ， 由 于 Drawable 的 默认 等 级 为 0， 那 么 ScaleDrawable 将 无 法 显 
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如 20000， 虽 然 也 能 正常 工作 ， 但 是 不 推荐 这 么 做 ， 这 是 因为 系统 内 部 
约定 Drawable 等 级 的 范围 为 0 到 10000。 


6.2.9 ClipDrawable 


ClipDrawable 对 应 于 <clip> 标 签 ， 它 可 以 根据 目 己 当前 的 等 级 

(level) 来 裁剪 另 一 个 Drawable ， 裁 前 方向 可 以 通过 

android:clipOrientation 和 android:gravity 这 两 个 属性 来 共同 控制 ， 它 的 
语法 如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 


<clip 


xmins:android="http://schemas.android.com/apk/res/android" 
android: drawable="@drawable/drawable resource" 


android:clipOrientation=["horizontal" | "vertical" ] 


android:gravity=["top" | "bottom"|"left" | 


"right"|"center_vertical" | 


"fill _vertical"|"center_horizontal"|'"fi11 horizontal" | 
"center" | 


"fi11"|"clip_vertical"|"clip_horizontal"] /> 


HF clipOrientatin% RRI 77 [A], AKFHEHMNTTFM, 
gravity 比 较 复 杂 ， nl: E 发 挥 作用 ， 如 表 6-4 所 
示 。 男 外 gravity 的 各 种 选项 是 可 以 通过 “来 组 合 使 用 的 。 


i 
FT 


表 6-4 ClipDrawableffgravityl&} 


WAI Drawable 放 在 容器 的 顶部 ， 不 改变 它 的 大 小 。 如 果 为 竖 直 裁剪 ， 那 么 从 底部 开始 裁剪 
bottom 将 内 部 的 Drawable 放 在 容器 的 底部 ， 不 改变 它 的 大 小 。 如 果 为 竖 直 裁剪 ， 那 么 从 顶部 开始 裁剪 
部 的 Drawable 放 在 容器 的 左边 ， 不 改变 它 的 大 小 。 如 果 为 水 平 裁剪 ， 那 么 从 右边 开始 裁剪 ， 这 


left 


right 将 内 部 的 Drawable 放 在 容器 的 右边 ， 不 改变 它 的 大 小 。 如 果 为 水 平 裁剪 ， 那 么 从 左边 开始 裁剪 
center_vertical ERBAY Drawable EAE EH, PREGRAD. MIRAR, MAME FRI RRI 
部 的 Drawable FEET fe] LEA. WU ER, MA ClipDrawable 的 等 级 为 0 (0 
ER ClipDrawable 被 完全 裁剪 ， 即 不 可 见 ) 时 ， 才 能 有 裁剪 行为 

使 内 部 的 Drawable 在 容器 中 水 平 居中 ， 不 改变 它 的 大 小 。 如 果 为 水 平 裁剪 ， 那 么 从 左右 两 边 同 时 开 
始 裁剪 


fill vertical 


center_horizontal 


di Py PAY Drawable 在 水 平方 向 上 填充 容器 。 如 果 为 水 平 裁剪 ,那么 仅 当 ClipDrawable 的 等 级 为 0 时 ， 
前 行为 
内 部 的 Drawable 在 容器 中 水 平和 竖 直 方向 都 居中 ， 不 改变 它 的 大 小 。 如 果 为 竖 直 裁剪 ， 那 么 从 上 
下 同时 开始 裁剪 ， 如 果 为 水 平 裁剪 ， 那 么 从 左右 同时 开始 裁剪 

使 内 部 的 Drawable 在 水 平和 竖 直 方向 上 同时 填充 容器 。 仅 当 ClipDrawable 的 等 级 为 0 时 ， 才 能 有 裁 
MATA 
clip_vertical MEMEH, Zea AT ARD, E 
clip_horizontal 附加 选项 ， 表 示 水 平方 向 的 裁剪 ， 


fill horizontal 


center 


fill 


下 面 举 个 例子 ， 我 们 实现 将 一 张 图 片 从 上 往 下 进行 裁剪 的 效果 ， 
首先 定义 ClipDrawable，xml 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 
<clip 
xmins:android="http://schemas.android.com/apk/res/android" 
android:clipOrientation="vertical" 
android: drawable="@drawable/image1" 


android: gravity="bottom" /> 


在 上 面 的 XML 中 ， 因 为 我 们 要 实现 顶部 的 裁剪 效果 ， 所 以 裁剪 
回应 该 为 竖 直 方 各 ， 同 时 从 表 6-4 可 以 知道 ，gravity 属 性 应 该 选择 
bottom。 有 了 ClipDrawable 如 何 使 用 呢 ? 也 是 很 简单 的 ， 首 移 将 它 设 置 
给 ImageView， 当 然 也 可 以 作为 普通 View 的 背景 ， 如 下 所 示 。 


<ImageView 
android:id="@+id/test_clip" 
android:layout_width="100dp" 
android:layout_height="100dp" 
android:src="@drawable/clip_drawable" 


android:gravity="center" /> 


接着 在 代码 中 设置 ClipDrawable 的 等 级 ， 如 下 所 示 。 


ImageView testClip = (ImageView) 
findViewById(R.id.test_clip); 
ClipDrawable testClipDrawable = (ClipDrawable) 
testClip.getDrawable(); 
testClipDrawable.setLevel(5000); 


在 6.2.5 节 中 已 经 提 到 ，Drawable 的 等 级 (level) 是 有 范围 的 ， 即 0 
人 10000， 最 小 等 级 是 0(， 最 大 等 级 是 10000， 对 于 ClipDrawable 来 说 ， 
等 级 0 表示 完全 裁剪 ， 即 整个 Drawable 都 不 可 见 了 ， 而 等 级 10000 表 示 
不 裁剪 。 在 上 面 的 代码 中 将 等 级 设置 为 8000 表 示 裁 前 了 2000， 即 在 项 
部 裁剪 掉 202%6 的 区 域 ， 被 裁剪 的 区 域 就 相当 于 不 存在 了 ， 具 体 效 果 如 
图 6-6 所 示 。 


图 6-6 ClipDrawable 的 裁剪 效果 


对 于 本 例 来 说 ， 等 级 越 大 ， 表 示 裁 前 的 区 域 越 小 ， 因 此 等 级 10000 
表示 不 裁剪 ， 这 个 时 候 整 个 图 片 都 可 以 完全 显示 出 来 ， 而 等 级 0 则 表示 
裁剪 全 部 区 域 ， 这 个 时 候 整 个 图 片 将 不 可 见 。 另 外 裁剪 效果 还 受 裁 剪 
方向 和 gravity 属 性 的 影响 ， 表 6-4 中 的 选项 读者 可 以 自行 党 试 一 下 ， 这 
样 就 能 比较 好 地 理解 不 同属 性 对 裁剪 效 末 的 影响 了 。 


6.3 HE YXDrawable 


Drawable 的 使 用 范围 很 单一 ， 一 个 是 作为 ImageView 中 的 图 像 来 显 
示 ， 男 外 一 个 就 是 作为 View 的 背景 ， 大 多 数 情 况 下 Drawable 都 是 以 
View 的 背景 这 种 形式 出 现 的 。Drawable 的 工作 原理 很 简单 ， 其 核心 就 
是 draw 方 法 。 在 第 5 章 中 ， 我 们 分 析 了 View 的 工作 原理 ， 我 们 知道 系 
统 会 调用 Drawable 的 draw 方 法 来 绘制 View 的 背景 ， 从 这 一 点 我 们 明 
日 ， 可 以 通过 重 写 Drawable 的 draw 方 法 来 自 定 义 Drawable 。 


通常 我 们 没有 必要 去 目 定 义 Drawable ， 这 是 因为 目 定义 的 
Drawable 无 法 在 XML 中 使 用 ， 这 束 降 低 了 目 定 义 Drawable 的 使 用 苑 
。 某 些 特殊 情况 下 我 们 的 确 想 目 定义 Drawable， 这 也 是 可 以 的 。 下 
面 演示 一 个 目 定义 Drawable 的 实现 过 程 ， 我 们 通过 上 自 定 义 Drawable 来 
绘制 一 个 圆 形 的 Drawable， 并 且 它 的 半径 会 随 着 View 的 变化 而 变化 ， 
这 种 Drawable 可 以 作为 View 的 通用 背景 ， 代 码 如 下 所 示 。 


public class CustomDrawable extends Drawable { 
private Paint mPaint; 
public CustomDrawable(int color) { 
mPaint = new Paint(Paint.ANTI_ALIAS FLAG); 
mPaint.setColor(color); 
} 
@Override 
public void draw(Canvas canvas) { 
final Rect r = getBounds(); 
float cx = r.exactCenterX(); 
float cy = r.exactCenterY(); 


canvas.drawCircle(cx,cy,Math.min(cx,cy),mPaint); 


@Override 

public void setAlpha(int alpha) { 
mPaint.setAlpha(alpha) ; 
invalidateSelf(); 

} 

@Override 

public void setColorFilter(ColorFilter cf) { 
mPaint.setColorFilter(cf); 
invalidateSelf(); 

y 

@Override 

public int getOpacity() { 
// not sure,so be safe 


return PixelFormat .TRANSLUCENT; 


} 


在 上 面 的 代码 中 ，draw、setAlpha、setColorFilter 和 getOpacity 这 几 
个 方法 都 是 必须 要 实现 的 ， 其 中 draw 是 最 主要 的 方法 ， 这 个 方法 就 和 
View 的 draw 方 法 类 似 ， 而 setAlpha、setColorFilter 和 getOpacity 这 三 个 
方法 的 实现 都 比较 简单 ， 这 里 不 再 多 说 了 。 在 上 面 的 例子 中 ， 参 考 了 
ShapeDrawable 和 BitmapDrawable 的 源码 ， 所 以 说 ， 源 码 是 一 个 很 好 的 
学 习 资 料 ， 有 些 技术 细节 我 们 不 清楚 ， 融 可 以 查看 源码 中 类 似 功 能 的 
实现 以 及 相应 的 文档 ， 这 样 就 可 以 更 有 和 针对 性 地 解决 一 些 问题 。 


上 面 的 例子 比较 简单 ， 但 是 流程 是 完整 的 ， 读 者 可 以 根据 自己 的 
需要 实现 更 复杂 的 目 定 义 Drawable。 % 外 getIntrinsicWidth 和 


getIntrinsicHeight 这 两 个 方法 需要 注意 一 下 ， 当 上 自 定 义 的 Drawable 有 
有 大 小 时 最 好 重 写 这 两 个 方法 ， 因 为 它 会 影响 到 View 的 wrap_content 
布局 ， 比 如 自 定 义 Drawable 是 绘制 一 张 图 片 ， 那 么 这 个 Drawable 的 内 
部 大 小 惑 可 以 选用 图 乒 的 大 小 。 在 上 面 的 例子 中 ， 目 定义 的 Drawable 
是 由 颜色 填充 的 圆 形 并 且 没 有 固定 的 大 小 ， 因 此 没有 重 写 这 两 个 方 
法 ， 这 个 时 候 它 的 内 部 大 小 为 -1， 即 内 部 宽度 和 内 部 高 度 都 为 -1。 需 
要 注意 的 是 ， 内 部 大 小 不 等 于 Drawable 的 实际 区 域 大 小 ，Drawable 的 
实际 区 域 大 小 可 以 通过 它 的 getBounds 方 法 来 得 到 ， 一 般 来 说 它 和 View 
的 尺寸 相同 。 


第 7 章 ” Android 动 画 深 入 分 析 


Android 的 动画 可 以 分 为 三 种 : View 动 画 、 帧 动画 和 属性 动画 ， 其 
实 帧 动画 也 属于 View 动 画 的 一 种 ， 只 不 过 它 和 平移 、 旋 转 等 第 见 的 
View 动 画 在 表现 形式 上 略 有 不 同 而 已 。View 动 画 通过 对 场景 里 的 对 象 
不 断 做 图 像 变 换 “平移 、 缩 放 、 旋 转 、 透 明度 ) 从 而 产生 动画 效果 ， 
它 是 一 种 渐 近 式 动画 ， 并 且 View 动 画 文 持 目 定义 。 帧 动画 通过 顺序 播 
放 一 系列 图 像 从 而 产生 动画 效果 ， 可 以 简单 理解 为 图 片 切换 动画 ， 很 
显然 ， 如 果 图 片 过 多 过 大 就 会 导 怪 O00M。 属 性 动画 通过 动态 地 改变 对 
象 的 属性 从 而 达到 动画 效 末 ， 属 性 动画 为 API 11 的 新 特性 ， 在 低 版 本 
无 法 直接 使 用 属性 动画 ， 但 是 我 们 仍然 可 以 通过 兼容 库 来 使 用 它 。 在 
本 章 中 ， 首 先 傈 单 介绍 View 动 画 以 及 目 定 义 View 动 画 的 方式 ， 接 着 介 
绍 View 动 画 的 一 些 特殊 的 使 用 场景 ， 最 后 对 属性 动画 做 一 个 全 面 性 的 
介绍 ， 男 外 还 介绍 使 用 动画 的 一 些 注意 事项 。 


7.1 View) 


View 动 画 的 作用 对 象征 View， 它 文 持 4 种 动画 效 末 ， 分 别 是 平移 
动画 、 缩 放 动 画 、 旋 转动 画 和 透明 度 动画 。 除 了 这 四 种 典型 的 变换 歼 
果 外 ， 帧 动画 也 属于 View 动 画 ， 但 是 帧 动画 的 表现 形式 和 上 面 的 四 种 
变换 效果 不 太一 样 。 为 了 更 好 地 区 分 这 四 种 变换 和 帧 动画 ， 在 本 章 中 
如 果 没 有 特殊 说 明 ， 那 么 所 提 到 的 View 动 画 均 指 这 四 种 变换 ， 帧 动画 
会 单独 介绍 。 本 市 将 介绍 View 动 画 的 四 种 效果 以 及 帧 动画 ， 同 时 还 会 
介绍 自 定义 View 动 画 的 方法 。 


7.1.1 View 动 画 的 种 类 


View 动 画 的 四 种 变换 效果 对 应 着 Animation 的 四 个 子 类 : 
TranslateAnimation ` ScaleAnimation >  RotateAnimation 和 
AlphaAnimation， 如 表 7-1 所 示 。 这 四 种 动画 既 可 以 通过 XML 来 定义 ， 
也 可 以 通过 代码 来 动态 创建 ， 对 于 View 动 画 来 说 ， 建 议 采 用 XML 来 定 
义 动画 ， 这 是 因为 XML 格式 的 动画 可 读 性 更 好 。 


表 7-1 _ View 动画 的 四 种 变换 


名 M 标 签 子 类 OR 


平移 动画 <translate> TranslateAnimation 移动 View 


缩放 动画 <scale> ScaleAnimation 放大 或 缩小 View 


旋转 动画 <rotate> RotateAnimation 旋转 View 


透明 度 动画 <alpha> AlphaAnimation 改变 View 的 透明 度 


要 使 用 View 动 画 ， 首 先 要 创建 动画 的 XML 文件 ， 这 个 文件 的 路 径 
为 : res/aniryfilename.xml。View 动 画 的 描述 文件 是 有 固定 的 语法 的 ， 
如 下 所 示 。 


<?xml version="1.0" encoding="utf-8"?> 
<set 


xmins:android="http://schemas.android.com/apk/res/android" 


android: interpolator="@[package: Janim/interpolator_resource" 
android:shareInterpolator=["true" | "false"] > 
<alpha 
android: fromAlpha="float" 
android: toAlpha="float" /> 


从 上 面 的 语法 可 以 看 出 ，View 动 画 既 可 以 是 单个 动画 ， 也 可 以 由 
一 系列 动画 组 成 。 


<set> 标 签 表示 动画 集合 ， 对 应 AnimationSet 类 ， 它 可 以 包含 春 干 
个 动画 ， 并 且 它 的 内 部 也 是 可 以 藤 套 其 他 动画 集合 的 ， 它 的 两 个 属性 


HIENA F: 
android:interpolator 


ADMIRAR es, ERE, EAE 
SER 5) E A A E ee Rl BOI © AAE En AA 
fae, HUA Oandroid:anim/accelerate_decelerate_interpolator, BEINE 
WARE as, ATA 67.3.2 HAT RMS > 


android:sharelnterpolator 


RRRA E E A - TEE E AN 
El, MATA A E AREA Be E H AA 
值 。 


<translate> 标 签 标示 平移 动画 ， 对 应 TranslateAnimation 类 ， 它 可 以 
使 一 个 View 在 水 平和 坚 直 方向 完成 平移 的 动画 效果 ， 它 的 一 系列 属性 
的 含义 如 下 : 


android:fromXDelta 


表示 x 的 起 始 值 ， 比 如 0; 
表示 x 的 结束 值 ， 比 如 100; 
表示 y 的 起 始 值 ; 
表示 y 的 结束 值 。 


android:toX Delta 


android:fromyY Delta 
android:toY Delta 


<Sscale> 标 俭 表 示 缩 放 动 画 ， 对 应 ScaleAnimation， 它 可 以 使 View 
具有 放大 或 者 缩小 的 动画 效果 ， 它 的 一 系列 属性 的 含义 如 下 : 


e android:fromXScale 


水 平方 向 缩放 的 起 始 值 ， 比 如 0.5; 
水 平方 向 缩放 的 结束 值 ， 比 如 1.2; 
竖 直 方向 缩放 的 起 始 值 ; 


e android:toXScale 


e android:fromY Scale 


竖 直 方向 缩放 的 起 始 值 ; 
缩放 的 轴 点 的 x 坐标 ， 它 会 影响 缩放 的 效果 ; 
缩放 的 轴 点 的 y 坐 标 ， 它 会 影响 缩放 的 效果 。 


e android:toY Scale 


e android:pivotX 


e android:pivotY 


在 <scale> 标 签 中 提 到 了 轴 点 的 概念 ， 这 里 举 个 例子 ， 默 认 情 况 下 
轴 点 是 View 的 中 心 点 ， 这 个 时 候 在 水 平方 向 进行 缩放 的 话 会 叶 致 View 
向 左右 两 个 方 同 同时 进行 缩放 ， 但 是 如 果 把 轴 点 设 为 View 的 右边 界 ， 
那么 View 束 只 会 同 左 边 进行 缩放 ， 反 之 则 疝 右 边 进 行 缩放 ， 具 体 效果 
读者 可 以 目 己 测试 一 下 。 


<rotate> 标 签 表 示 旋 转动 画 ， 对 于 RotateAnimation， 它 可 以 使 View 
具有 旋转 的 动画 效果 ， 它 的 属性 的 含义 如 下 : 


旋转 开始 的 角度 ， 比 如 0; 
旋转 结束 的 角度 ， 比 如 180; 
旋转 的 轴 点 的 x 坐标 ; 
旋转 的 轴 点 的 y 坐 标 。 


e android:fromDegrees 


e android:toDegrees 


e android:pivotX 


e android:pivotY 


在 旋转 动画 中 也 有 轴 点 的 概念 ， 它 也 会 影响 到 旋转 的 具体 效果 。 
在 旋转 动画 中 ， 轴 扣 扮 演 着 旋转 轴 的 角色 ， 即 View 古 围绕 着 轴 扣 进行 
BER, 默认 情况 下 轴 点 为 View 的 中 心 护 。 考 虑 一 种 情况 ，View 围 绕 
着 自己 的 中 心 点 和 围绕 着 自己 的 左上 角 旋 转 90 度 显然 是 不 同 的 旋转 轨 
迹 ， 不 同 轴 点 对 旋转 效果 的 影响 读者 可 以 目 己 测试 一 下 。 


<alpha> 标 签 表示 透明 度 动画 ， 对 应 AlphaAnimation， 它 可 以 改变 
View 的 透明 度 ， 它 的 属性 的 含义 如 下 : 


表示 透明 度 的 起 始 值 ， 比 如 0.1; 
表示 透明 度 的 结束 值 ， 比 如 1 。 


e android:fromAlpha 


e android:toAlpha 


上 面 简单 介绍 了 View 动 画 的 XML 格式 ， 具 体 的 使 用 方法 查看 相关 
文档 。 除 了 上 面 介 绍 的 属性 以 外 ，View 动 画 还 有 一 些 常用 的 属性 ， 如 
Pra? 


e android:duration: 动画 的 持续 时 间 
。 android:fillAfter 一 一 动画 结束 以 后 View 是 否 停留 在 结束 位 置 ，true 
表示 View 停 留 在 结束 位 置 ，false 则 不 停留 。 


下 面 是 一 个 实际 的 例子 : 


android:toDegrees="90" /> 


</set> 


如 何 应 用 上 面 的 动画 呢 ? 也 很 简单 ， 如 下 所 示 。 


Button mButton = (Button) findViewById(R.id.button1); 


Animation animation 


AnimationUtils.loadAnimation(this,R.anim.animation_ 


test); 


mButton.startAnimation(animation) ; 


除了 在 XML 中 定义 动画 外 ， 还 可 以 通过 代码 来 应 用 动画 ， 这 里 举 


BIT, RIE RAS > 


AlphaAnimation alphaAnimation = new AlphaAnimation(0,1); 
alphaAnimation.setDuration(300); 


mButton.startAnimation(alphaAnimation); 


在 上 面 的 代码 中 ， 创 建 了 一 个 透明 度 动画 ， 将 一 个 Button 的 透明 


度 在 300ms 内 由 0 变 为 1， 其 他 类 型 的 View 动 画 也 可 以 通过 代码 来 创 
建 ， 这 里 就 不 做 介绍 了 。 男 外 ， 通 过 Animation 的 setAnimationListener 
方法 可 以 给 View 动 画 添加 过 程 监 昕 ， 接 口 如 下 所 示 。 从 接口 的 定义 可 
以 很 清楚 地 看 出 每 个 方法 的 含义 。 


public static interface AnimationListener { 
void onAnimationStart(Animation animation); 
void onAnimationEnd(Animation animation); 


void onAnimationRepeat(Animation animation); 


7.1.2 ”上 和 目 定 义 View 动 画 


除了 系统 提供 的 四 种 View 动 画 外 ， 我 们 还 可 以 目 定 义 View 动 画 。 
目 定 义 动 画 是 一 件 既 简单 又 复杂 的 事情 ， 说 它 简 单 ， 是 因为 派生 一 种 
新 动画 只 需要 继承 Animation 这 个 抽象 类 ， 然 后 重 写 它 的 initialize 和 
applyTransformation 方 法 ， 在 initialize 方 法 中 做 一 些 初 始 化 工作 ， 在 
applyTransformation 中 进行 相应 的 矩阵 变换 即 可 ， 很 多 时 候 需要 采用 
Camera 来 简化 矩阵 变换 的 过 程 。 说 它 复 杂 ， 是 因为 目 定 义 View 动 画 的 
过 程 主要 是 矩阵 变换 的 过 程 ， 而 矩阵 变换 是 数学 上 的 概念 ， 如 有 果 对 这 
方面 的 知识 不 驶 悉 的 话 ， 残 会 觉得 这 个 过 程 比较 复杂 了 。 


本 贡 不 打算 详细 地 讲解 目 定 义 View 动 画 的 细节 ， 因 为 这 都 是 数学 
中 的 矩阵 变换 的 细节 ， 读 者 只 需要 知道 日 定义 View 的 方法 并 在 需要 的 
时 候 参 考 矩 阵 变 换 的 细 市 即 可 写 出 特定 的 目 定 义 View 动 画 。 一 般 来 
说 ， 在 实际 开发 中 很 少 用 到 目 定 义 View 动 画 。 这 里 提供 一 个 自 定 义 
View 动 画 的 例 季 ， 这 个 例子 来 目 于 Android 的 ApiDemos 中 的 一 个 目 定 
义 View 动 画 Rotate3dAnimation。Rotate3dAnimation 可 以 围绕 y 轴 旋转 并 
且 同 时 沿 着 z 轴 平移 从 而 实现 一 种 类 似 于 3D 的 效果 ， 它 的 代码 如 下 : 


public class Rotate3dAnimation extends Animation { 
private final float mFromDegrees; 
private final float mToDegrees; 
private final float mCenterX; 
private final float mCenterY; 
private final float mDepthZ; 
private final boolean mReverse; 


private Camera mCamera; 
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帧 动画 是 顺序 播放 一 组 预先 定义 好 的 图 片 ， 类 似 于 电影 播放 。 不 
同 于 View 动 画 ， 系 统 提 供 了 另外 一 个 类 AnimationDrawable 来 使 用 帧 动 
画 。 帧 动画 的 使 用 比较 简单 ， 首 先 需 要 通过 XML 来 定义 一 个 
AnimationDrawable， 如 下 所 示 。 


// res/drawable/frame_animation.xml 
<?xml version="1.0" encoding="utf-8"?> 
<animation-list 
xmins:android="http://schemas.android.com/apk/res/android" 
android: oneshot="false"> 
<item android:drawable="@drawable/imaget" 
android:duration="500" /> 
<item android:drawable="@drawable/image2" 
android:duration="500" /> 
<item android:drawable="@drawable/image3" 
android:duration="500" /> 


</animation-list> 


然后 将 上 述 的 Drawable 作 为 View 的 背景 并 通过 Drawable 来 播放 动 
EJEN RJ: 


Button mButton = (Button)findViewById(R.id.button1); 
mButton.setBackgroundResource(R.drawable.frame_animation); 
AnimationDrawable drawable = (AnimationDrawable) 
mButton.getBackground(); 


drawable.start(); 


帧 动画 的 使 用 比较 简单 ， 但 是 比较 容易 引起 OOM， 所 以 在 使 用 帧 
动画 时 应 尽量 避免 使 用 过 多 尺寸 较 大 的 图 片 。 
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View 动 画 还 可 以 在 一 些 特殊 的 场景 下 使 用 ， 比 如 在 ViewGroup 中 可 以 
控制 子 元 素 的 出 场 效果 ， 在 Activity 中 可 以 实现 不 同 Activity 之 间 的 切 
换 效 果 。 


7.2.1 LayoutAnimation 


LayoutAnimation 作 用 于 ViewGroup ， 为 ViewGroup 指 定 一 个 动画 ， 
这 样 当 它 的 子 元 素 出 场 时 都 会 具有 这 种 动画 效果 。 这 种 效果 常常 被 用 
在 ListView 上 ， 我 们 时 常会 看 到 一 种 特殊 的 ListView， 它 的 每 个 item 都 
以 一 定 的 动画 的 形式 出 现 ， 其 实 这 并 非 什么 高 深 的 技术 ， 它 使 用 的 就 
Æ LayoutAnimation ° LayoutAnimation 也 是 一 个 View 动 画 ， 为 了 给 


ViewGroup 的 子 元 素 加 上 出 场 效果 ， 尊 循 如 下 几 个 步 又 。 


(1) 定义 LayoutAnimation， 如 下 所 示 。 
// res/anim/anim layout.xml 


<layoutAnimation 


xmins:android="http://schemas.android.com/apk/res/android" 
android: delay="0.5" 
android:animationOrder="normal" 


android: animation="@anim/anim_item"/> 
它 的 属性 的 含义 如 下 所 示 。 


android: delay 


表示 子 元 素 开始 动画 的 时 间 延 迟 ， 比 如 子 元 素 入 场 动 画 的 时 间 周 
期 为 300ms， 那 么 0.5 表 示 每 个 子 元 素 都 需要 延迟 150ms 才 能 播放 入 场 
动画 。 总 体 来 说 ， 第 一 个 子 元 素 延 迟 150ms 开 始 播放 入 场 动画 ， 人 第 2 个 
子 元 素 延 迟 300ms 开 始 播放 入 场 动画 ， 依 次 类 推 。 


android:animationOrder 


表示 子 元 素 动 画 的 顺序 ， 有 三 种 选项 : normal ` reverse 和 
random， 其 中 normal 表 示 顺 序 显示 ， 即 排 在 前 面 的 子 元 素 先 开始 播放 
入 场 动画 ;reverse 表 示 逆 同 显 示 ， 即 排 在 后 面 的 子 元 素 先 开始 播放 入 
场 动 画 ; random 则 是 随机 播放 入 场 动画 。 


android:animation 


为 子 元素 指 定 具 体 的 入 场 动 画 。 


(2) 为 子 元 素 指定 具体 的 入 场 动画 ， 如 下 所 示 。 


// res/anim/anim_item.xml 
<?xml version="1.0" encoding="utf-8"?> 
<set 
xmlns:android="http://schemas.android.com/apk/res/android" 


android:duration="300" 


android: interpolator="@android:anim/accelerate_interpolator" 
android:shareInterpolator="true" > 
<alpha 
android: fromAlpha="0.0" 


android: toAlpha="1.0" /> 


<translate 
android: fromXDelta="500" 
android:toXDelta="0" /> 


</set> 


(3) 为 ViewGroup FE ¿E android:layoutAnimation 属性 : 
android:layoutAnimation= "@anim/ anim_layout"。 对 于 ListView 来 说 ， 
这 样 ListView 的 item 就 具有 出 场 动画 了 ， 这 种 方式 适用 于 所 有 的 
ViewGroup, 40 RATA ° 


<ListView 
android: id="@+id/list" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: LayoutAnimation="@anim/anim_layout" 
android: background="#fff4f7f9" 
android: cacheColorHint="#00000000" 
android: divider="#dddbdb" 
android: dividerHeight="1.0px" 


android: listSelector="@android:color/transparent" /> 


除了 在 XML 中 指定 LayoutAnimation 外 ， 还 可 以 通过 
LayoutAnimationController 来 实现 ， 有 具体 代码 如 下 所 示 。 


ListView listView = (ListView) 
layout.findViewById(R.id.list); 
Animation animation = 


AnimationUtils.loadAnimation(this,R.anim.anim_ 


item); 
LayoutAnimationController controller = new 
LayoutAnimationController 
(animation); 


controller.setDelay(0.5f); 


controller.setOrder(LayoutAnimationController.ORDER_NORMAL ) ; 


listView.setLayoutAnimation(controller); 


7.2.2 Activity 切换 效果 


Activity 有 默认 的 切换 效 末 ， 但 是 这 个 效果 我 们 是 可 以 目 定 义 的 ， 
主要 用 到 overridePendingTransition(int enterAnim,int exitAnim) 这 个 方 
法 ， 这 个 方法 必须 在 startActivity(Inten0 或 者 finish0O 之 后 被 调用 才能 
效 ， 它 的 参数 含义 如 下 : 


e enterAnim: 


Activity 被 打开 时 ， 所 需 的 动画 资源 id; 
Activity 被 暂 俘 时 ， 所 需 的 动画 资源 id 。 


e exitAnim 
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Intent intent = new Intent(this, TestActivity.class); 


startActivity(intent); 


overridePendingTransition(R.anim.enter_anim,R.anim.exit_anim); 


当 Activity 退 出 时 ， 也 可 以 为 其 指定 目 己 的 切换 效 末 ， 如 下 所 示 。 


@Override 
public void finish() { 


super.finish(); 


overridePendingTransition(R.anim.enter_anim,R.anim.exit_anim); 
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需要 注意 的 是 ，overridePendingTransition 这 个 方法 必须 位 于 
startActivity 或 者 finish 的 后 面 ， 否 则 动画 效 末 将 不 起 作用 。 


Fragment 也 可 以 添加 切换 动画 ， 由 于 Fragment 是 在 API 11 中 新 引入 
的 类 ， 因 此 为 了 兼容 性 我 们 需要 使 用 support-v4 这 个 兼容 包 ， 在 这 种 情 
况 下 我 们 可 以 通过 FragmentTransaction 中 的 setCustomAnimations() 方 法 
来 添加 切换 动画 。 这 个 切换 动画 需要 是 View 动 男 ， 之 所 以 不 能 采用 属 
性 动画 是 因为 属性 动画 也 是 API 11 狐 引入 的 。 还 有 其 他 方式 可 以 给 
Activity 和 Fragment 添 加 切换 动画 ， 但 是 它们 大 多 都 有 兼容 性 问题 ， 在 
低 版 本 上 无 法 使 用 ， 因 此 不 具有 很 高 的 使 用 价值 ， 这 里 就 不 再 一 一 介 
TA 
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属性 动画 是 API 11 狐 加 入 的 特性 ， 和 View 动 画 不 同 ， 它 对 作用 对 
象 进行 了 扩展 ， 属 性 动画 可 以 对 任何 对 象 做 动画 ， 其 至 还 可 以 没有 对 
象 。 除 了 作用 对 象 进行 了 扩展 以 外 ， 属 性 动画 的 效果 也 得 到 了 加 强 ， 
不 再 像 View 动 画 那样 只 能 文 持 四 种 简单 的 变换 。 属 性 动画 中 有 


ValueAnimator、ObjectAnimator 和 AnimatorSet 等 概念 ， 通 过 它们 可 以 
实现 绚丽 的 动画 。 


7.3.1 使 用 属性 动画 


属性 动画 可 以 对 任意 对 象 的 属性 进行 动画 而 不 仅仅 是 View， 动 画 
默认 时 间 间 隔 300ms， 默 认 帧 率 10ms/ 帧 。 其 可 以 达到 的 效果 是 : 在 一 
个 时 间 间 隔 内 完成 对 象 从 一 个 属性 值 到 另 一 个 属性 值 的 改变 。 因 此 ， 
属性 动画 几乎 是 无 所 不 能 的 ， 只 要 对 象 有 这 个 属性 ， 它 都 能 实现 动画 
效果 。 但 是 属性 动画 从 API 11 才 有 ， 这 就 严重 制约 了 属性 动画 的 使 
用 。 可 以 采用 开源 动画 库 nineoldandroids 来 兼容 以 前 的 版 本 ， 采 用 
nineoldandroids ， 可 以 在 API 11 以 前 的 系统 上 使 用 属性 动画 ， 
nineoldandroids 的 网 址 是 : http://nineoldandroids.com ° 


Nineoldandroids 对 属性 动画 做 了 兼容 ， 在 API 11 以 前 的 版 本 其 内 部 
是 通过 代理 View 动 画 来 实现 的 ， 因 此 在 Android 低 版 本 上 ， 它 的 本 质 还 
是 View 动 画 ， 尽 管 使 用 方法 看 起 来 是 属性 动画 。Nineoldandroids 的 功 
能 和 系统 原生 对 的 android.animation.* 中 类 的 功能 完全 一 致 ， 使 用 方法 
也 完全 一 样 ， 只 要 我 们 用 nineoldandroids 来 编写 动画 ， 就 可 以 在 所 有 的 
Android 系 统 上 运行 。 比 较 常 用 的 几 个 动画 类 是 : ValueAnimator ` 
ObjectAnimator 和 AnimatorSet , 其 中 ObjectAnimator 继 承 H 
ValueAnimator，AnimatorSet 是 动画 集合 ， 可 以 定义 一 组 动画 ， 它 们 使 
用 起 来 也 是 极其 简单 的 。 如 何 使 用 属性 动画 呢 ? 下 面 简 单 举 儿 个 小 例 
子 ， 读 者 一 看 就 明日 了 。 


(1) 改变 一 个 对 象 (myObject) 的 translationY 属 性 ， 让 其 沿 着 Y 
轴 癌 上 平移 一 段 距 离 : 它 的 高 度 ， 该 动画 在 默认 时 间 内 完成 ， 动 画 的 
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估 值 算法 ， 但 是 一 般 来 说 我 们 不 需要 自 定 义 ， 系 统 已 经 预 置 了 一 些 ， 
能 够 满足 常用 的 动画 。 


ObjectAnimator.ofFloat(myObject, "translationy", - 
myObject.getHeight()). 
start(); 


(2) 改变 一 个 对 象 的 背景 色 属 性 ， 典 型 的 情形 是 改变 View 的 背 
景色 ， 下 面 的 动画 可 以 让 背景 色 在 3 秒 内 实现 从 0xFFFF8080 到 
0xFF8080FF 的 渐变 ， 动 画 会 无 限 循 环 而 且 会 有 反 转 的 效果 。 


ValueAnimator colorAnim = 
ObjectAnimator.ofInt(this, "backgroundColor", 
/*Red*/0xFFFF8080, /*Blue*/0xFF8080FF) ; 
colorAnim.setDuration(3000); 
colorAnim.setEvaluator(new ArgbEvaluator()); 
colorAnim.setRepeatCount (ValueAnimator.INFINITE); 
colorAnim. setRepeatMode(ValueAnimator ..REVERSE); 


colorAnim.start(); 


(3) HERE, SPAN Views hehe + PAS > ARROB ADA 
行 了 改变 。 


AnimatorSet set = new AnimatorSet(); 
set.playTogether ( 
ObjectAnimator.ofFloat(myView, "rotationX",0,360), 


ObjectAnimator.ofFloat(myView, "rotationY",0,180), 


ObjectAnimator.ofFloat(myView, "rotation",0,-90), 
ObjectAnimator.ofFloat(myView, "translationX",0,90), 
ObjectAnimator.ofFloat(myView, "translationY",0,90), 
ObjectAnimator.ofFloat(myView, "scaleX",1,1.5f), 
ObjectAnimator.ofFloat(myView, "scaleY",1,0.5f), 
ObjectAnimator.ofFloat(myView, "alpha",1,0.25f,1) 
); 
set.setDuration(5 * 1000).start(); 


属性 动画 除了 通过 代码 实现 以 外 ， 还 可 以 通过 XML 来 定义 。 属 性 
动画 需要 定义 在 res/animator/ 目 录 下 ， 它 的 语法 如 下 所 示 。 


<set 
android:ordering=["together" | "sequentially"]> 
<objectAnimator 
android:propertyName="string" 
android:duration="int" 
android:valueFrom="float | int | color" 
android:valueTo="float | int | color" 
android:startOffset="int" 


android:repeatCount="int" 


android:repeatMode=["repeat" | "reverse" | 
android:valueType=["intType" | "floatType"]/> 
<animator 


android:duration="int" 
android:valueFrom="float | int | color" 


android:valueTo="float | int | color" 


android:startOffset="int" 


android: repeatCount="int" 


android: repeatMode=["repeat" | "reverse" | 
android: valueType=["intType" | "floatType"]/> 
<set> 
</set> 


</set> 


属性 动画 的 各 种 参数 都 比较 好 理解 ， 在 XML 中 可 以 定义 
ValueAnimator、Object-Animator 以 及 AnimatorSet， 其 中 <set> 标 签 对 应 
AnimatorSet , <Animator> 标 签 对 应 ValueAnimator , 而 
<objectAnimator> 则 对 应 ObjectAnimator。 <set> 标 签 的 android:ordering 
属性 有 两 个 可 选 值 : “together” All“sequentially”, H F “together” RIRI) 
画集 合 中 的 子 动画 同时 播放 , “sequentially” 则 表示 动画 集合 中 的 子 动 
画 按 照 前 后 顺序 依次 播放 ，android:ordering 属 性 的 默认 值 


E “together” ° 
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下 ， 对 于 <Animator> 标 签 这 里 就 不 再 介绍 了 ， 为 它 只 是 比 
<objectAnimator> 少 了 一 个 android:propertyName 属 性 而 已 ， 其 他 都 是 一 
样 的 。 


e android:propertyName 表示 属性 动画 的 作用 对 象 的 属性 的 名 
BR; 


e android:duration 


表示 动画 的 时 长 ; 
表示 属性 的 起 始 值 ; 
表示 属性 的 结束 值 ; 


e android:valueFrom 


e android: value'To 


e android:startOffset 一 表示 动画 的 延迟 时 间 ， 当 动画 开始 后 ， 需 要 
延迟 多 少 毫 秒 才 会 真正 播放 此 动画 ; 

表示 动画 的 重复 次 数 ; 

表示 动画 的 重复 模式 ; 

e android:valueType 表示 android:propertyName 上 所 指定 的 属性 的 
类 型 ， 有 “intType” 和 “floatType” 两 个 可 选项 ， 分 别 表示 属性 的 类 
型 为 整 型 和 浮 点 型 。 男 外 ， 如 果 android:propertyName 所 指定 的 属 
性 表示 的 是 颜色 ， 那 么 不 需要 指定 android:valueType， 系 统 会 目 动 
对 颜色 类 型 的 属性 做 处 理 。 


e android:repeatCount 


e android:repeatMode 


对 于 一 个 动画 来 说 ， 有 两 个 属性 这 里 要 特殊 说 明 一 下 ， 一 个 是 
android:repeatCount， 它 表示 动画 循环 的 次 数 ， 默 认 值 为 0， 其 中 -1 表 
示 无 限 循环 )， 另 一 个 是 android:repeatMode， 它 表示 动画 循环 的 模式 ， 
有 两 个 选项 : “repeat Al “reverse”, 2) 5!) FE7NEAE Ee BS MEER o E 
续 重 复 比 较 好 理解 ， 束 是 动画 每 次 都 重新 开始 播放 ， 而 赣 回 重复 是 指 
第 一 次 播放 完 以 后 ， 第 二 次 会 倒 着 播放 动画 ， 第 三 次 再 重头 开始 播放 
动画 ， 第 四 次 再 倒 着 播放 动画 ， 如 此 反复 。 


下 面 钙 一 个 具体 的 例子 ， 我 们 通过 XML 定 义 一 个 属性 动画 并 将 其 
作用 在 View 上 ， 如 下 所 示 。 


// res/animator/property_animator.xml 
<set android:ordering="together"> 
<objectAnimator 
android:propertyName="x" 
android:duration="300" 
android:valueTo="200" 


android:valueType="intType"/> 


<objectAnimator 
android:propertyName="y" 
android:duration="300" 
android:valueTo="300" 
android:valueType="intType"/> 


</set> 


如 何 使 用 上 面 的 属性 动画 呢 ? 也 很 简单 ， 如 下 所 示 。 


AnimatorSet set = (AnimatorSet ) 
AnimatorInflater.loadAnimator (myContext, 
R.anim.property_animator); 
set.setTarget (mButton); 


set.start(); 


在 实际 开发 中 建议 采用 代码 来 实现 属性 动画 ， 这 是 因为 通过 代码 
来 实现 比较 人 简单。 更 重要 的 是 ， 很 多 时 候 一 个 属性 的 起 始 值 是 无 法 提 
前 确定 的 ， 比 如 让 一 个 Button 从 屏幕 左边 移动 到 屏幕 的 右边 ， 由 于 我 
们 无 法 提前 知道 屏幕 的 冤 度 ， 因 此 无 法 将 属性 动画 定义 在 XML 中 ， 在 
这 种 情况 下 束 必 须 通 过 代码 来 动态 地 创建 属性 动画 。 
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逝 的 百分比 来 计算 出 当前 属性 值 改 变 的 百分比 ， 系 统 预 置 的 有 
LinearInterpolator (线性 插值 器 : © Æ 5J m) 
AccelerateDecelerateInterpolator (加 速 减 速 插值 器 : 动画 两 头 慢 中 间 


ER) Fi Decelerate-Interpolator (减速 插值 器 : 动画 越 来 越 慢 ) 等 
TypeEvaluator 的 中 文 翻译 为 类 型 估 值 算法 ， 也 叫 佑 值 侨 ， 它 的 作用 是 
根据 当前 属性 改变 的 百分比 来 计算 改变 后 的 属性 值 ， 系统 预 置 的 有 
IntEvaluator (针对 整 型 属性 ) 、FloatEvaluator (针对 浮 点 型 属性 ) 和 
ArgbEvaluator (针对 Color 属 性 ) 。 属 性 动画 中 的 插值 器 

(Interpolator) 和 估 值 器 (TypeEvaluator) 很 重要 ， 它 们 是 实现 非 勺 
速 动 画 的 重要 手段 。 可 能 这 么 说 还 有 点 星 深 ， 没 关系 ， 下 面 给 出 一 个 
实例 瓯 很 好 理解 了 


如 图 7-1 所 示 ， 它 表示 一 个 勺 速 动画 ， 采 用 了 线性 插值 右 和 整 型 估 
值 算 法 ， 在 40ms 内 ，View 的 x 属性 实现 从 0 到 40 的 变换 。 


= ES x=40 
t= ES t = 40ms 


SEFFER 


图 7-1 ”插值 器 的 工作 原理 GE: 此 图 来 自 Android 官 方 文档 ) 


由 于 动画 的 默认 刷新 率 为 10ms/ 帧 ， 所 以 该 动画 将 分 5 帧 进行 ， 我 
们 来 考虑 第 三 帧 (x=20, t=20ms) ， 当 时 间 人 20ms 的 时 候 ， 时 间 流 逝 
的 百分比 是 0.5 (20/40=0.5) ， 意 味 着 现在 时 间 过 了 一 半 ， 那 x 应 该 改 
AS Me? 这 个 就 由 插值 器 和 估 值 算法 来 确定 。 拿 线性 插值 器 来 说 ， 
当时 间 流 挝 一 半 的 时 候 ，x 的 变换 也 应 该 是 一 半 ， 即 x 的 改变 是 0.5， 为 
什么 呢 ? 因 为 它 是 线性 插值 器 ， 是 实现 匀速 动画 的 ， 下 面 看 它 的 源 
码 : 


很 显然 ， 线 性 插值 器 的 返回 值 和 输入 值 一 样 ， 因 此 插值 器 返回 的 
值 是 0.5， 这 意味 着 x 的 改变 是 0.5， 这 个 时 候 插 值 器 的 工作 就 完成 了 。 
具体 x 变 成 了 什么 值 ， 这 个 需要 估 值 算法 来 确定 ， 我 们 来 看 看 整 型 估 值 
算法 的 源码 : 


上 述 算 法 很 简单 ，evaluate 的 三 个 参数 分 别 表示 估 值 小 数 、 开 始 值 
和 结束 值 ， 对 应 于 我 们 的 例子 就 分 别 是 0.5、0、40。 根 据 上 述 算法 ， 
整 型 信 值 返回 给 我 们 的 结果 是 20， 这 束 是 (x=20，t=20ms) 的 由 来 。 


属性 动画 要 求 对 象 的 该 属性 有 set 方 法 和 get 方 法 (可 选 ) > Bas 
和 估 值 算法 除了 系统 提供 的 外 ， 我 们 还 可 以 目 定义 。 实 现 方式 也 很 简 
单 ， 因 为 插值 右 和 估 值 算法 都 是 一 个 接口 ， 且 内 部 都 只 有 一 个 方法 ， 
我 们 只 要 派生 一 个 类 实现 接口 就 可 以 了 ， 然 后 就 可 以 做 出 千奇百怪 的 
动画 效果 了 。 具 体 一 点 就 是 : 目 定 义 揪 值 絮 需 要 实现 Interpolator 或 者 
TimelInter-polator， 自 定义 估 值 算法 需要 实现 TypeEvaluator。 男 外 就 是 
如 果 要 对 其 他 类 型 ( 非 int、float、Color) 做 动画 ， 那 么 必须 要 自 定 义 
类 型 佑 值 算 法 。 


733 ”属性 动画 的 监听 希 


属性 动画 提供 了 监听 万 用 于 监听 动画 的 播放 过 程 ， 主 要 有 如 下 两 


个 接口 : AnimatorUpdateListener 和 AnimatorListener ° 


AnimatorListener 的 定义 如 下 : 


public static interface AnimatorListener { 
void onAnimationStart(Animator animation); 
void onAnimationEnd(Animator animation); 
void onAnimationCancel(Animator animation); 


void onAnimationRepeat(Animator animation); 


从 AnimatorListener 的 定义 可 以 看 出 ， 它 可 以 监听 动画 的 开始 、 结 
束 、 取 消 以 及 重复 播放 。 同 时 为 了 方便 开发 ， 系 统 还 提供 了 
AnimatorListenerAdapteriX ^, E Œ Animator-Listener AY ia AC at , 
BAT A Dace SEE EMA THIET, RSE AERP ATTIRED 
是 我 们 感 兴趣 的 。 


下 面 再 看 一 下 AnimatorUpdateListener 的 定义 ， 如 下 所 示 。 


public static interface AnimatorUpdateListener { 
void onAnimationUpdate(ValueAnimator animation); 


} 


AnimatorUpdateListener 比 较 特殊 ， 它 会 监听 整个 动画 过 程 ， 动 画 
是 由 许多 帧 组 成 的 ， 每 播放 一 帧 ，onAnimationUpdate 就 会 被 调用 一 
次 ， 利 用 这 个 特性 ， 我 们 可 以 做 一 些 特 殊 的 事情 。 


73.4 对 任意 属性 做 动画 


这 里 移 提 出 一 个 问题 : 给 Button 加 一 个 动画 ， 让 这 个 Button 的 宽度 
从 当前 宽度 增加 到 500px。 也 许 你 会 说 ， 这 很 简单 ， 用 View 动 画 束 可 
以 搞定 ， 我 们 可 以 来 试 试 ， 你 能 写 出 来 吗 ? 很 快 你 就 会 悦 然 大 悟 ， 原 
来 View 动 画 根本 不 文 持 对 宽度 进行 动画 。 没 错 ，View 动 男 只 文 持 四 种 
类 型 : 平移 (Translate) 、 旋 转 (Rotate) 、 缩 放 (Scale) 、 不 透明 度 
(Alpha) 。 当 然 用 x 方向 缩放 (scaleX) 可 以 让 Button 在 x 方 向 放大 ， 
看 起 来 好 像 是 宽度 增加 了 ， 实 际 上 不 是 ， 只 是 Button 被 放大 了 而 已 ， 
而 且 由 于 只 x 方 向 被 放大 ， 这 个 时 候 Button 的 背景 以 及 上 面 的 文本 都 被 
拉 伸 了 ， 甚 至 有 可 能 Button 会 超出 屏幕 ， 如 图 7-2 所 示 。 
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图 7-2 ”属性 动画 的 缩放 效果 


图 7-2 中 的 效果 显然 是 很 差 的 ， 而 且 也 不 是 真正 地 对 冤 度 做 动画 ， 
不 过 ， 上 所幸 我 们 还 有 属性 动画 ， 我 们 用 属性 动画 斌 起 ， 如 下 所 示 。 


private void performAnimate() { 


ObjectAnimator.ofInt(mButton, "width",500).setDuration(5000).sta 
rt(); 
t 
@Override 
public void onClick(View v) { 
if (v == mButton) { 


performAnimate(); 
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一 个 属性 过 去 ， 轻 则 没 动画 效果 ， 重 则 程序 直接 Crash 。 


下 面 分 析 属 性 动画 的 原理 :属性 动画 要 求 动 画作 用 的 对 象 提 供 该 
属性 的 get 和 set 方 法 ， 属 性 动画 根据 外 界 传递 的 该 属性 的 初始 值 和 最 终 


值 ， 以 动画 的 效果 多 次 去 调用 set 方 法 ， 每 次 传递 给 set 方 法 的 值 都 不 一 
样 ， 确 切 来 说 是 随 痢 时 间 的 推移 ， 所 传递 的 值 越 来 越 接 近 最 终 值 。 总 
结 一 下 ， 我 们 对 object 的 属性 abc 做 动画 ， 如 果 想 让 动画 生效 ， 要 同时 
满足 两 个 条 件 : 


(1) object 必 须要 提供 setAbc 方 法 ， 如 果 动 画 的 时 候 没 有 传递 初 
台 值 ， 那 么 还 要 提供 getAbc 方 法 ， 因 为 系统 要 去 取 abc 属 性 的 初始 值 
(如 果 这 条 不 满足 ， 程 序 直 接 Crash) 


(2) object 的 setAbc 对 属性 abc 所 做 的 改变 必须 能 够 通过 某 种 方法 
反映 出 来 ， 比 如 会 带 来 UI 的 改变 之 类 的 〈 如 果 这 条 不 满足 ， 动 画 无 效 
果 但 不 会 Crash ) 


以 上 条 件 缺 一 人 不可。 那么 为 什么 我 们 对 Button 的 width 属性 做 动画 
会 没有 效果 ? 这 是 因为 Button 内 部 虽然 提供 了 getWidth 和 setWidth 方 
法 ， 但 是 这 个 setWidth 方 法 并 不 是 改变 视图 的 大 小 ， 它 是 TextView 狐 湛 
加 的 方法 ，View 是 没有 这 个 setWidth 方法 的 ， 由 于 Button 继 承 了 
TextView ， 所 以 Button 也 就 有 了 setWidth 方法。 和 下面 看 一 下 这 个 
getWidth 和 setWidth 方 法 的 源码 : 


[fp vrs 
* Makes the TextView exactly this many pixels wide. 
* You could do the same thing by specifying this number 
in the 
* LayoutParams. 
* 
* (see #setMaxWidth(int) 


* (see #setMinWidth(int) 


从 上 述 源 码 可 以 看 出 ，getWidth 的 确 是 获取 View 的 宽度 的 ， 而 
setWidth 是 TextView 和 其 子 类 的 专属 方法 ， 它 的 作用 置 View 的 
宽度 ， 而 是 设置 TextView 的 最 大 宽度 和 最 小 宽度 的 ， 这 个 和 TextView 
的 宽度 不 是 一 个 东西 。 具 体 来 说 ，TextView 的 宽 中 的 
android:layout_width 必 性， 而 TextView 还 有 一 个 属性 android:width， 这 


个 android:width 属性 就 对 应 了 TextView 的 setWidth 方法 。 总 之 ， 
TextView 和 了 Button 的 setWidth、getWidth 干 的 不 是 同一 件 事情 ， 通 过 
setWidth 无 法 改变 控件 的 宽度 ， 所 以 对 width 做 属性 动画 没有 效果 。 对 
应 于 属性 动画 的 两 个 条 件 来 说 ， 本 例 中 动画 不 生效 的 原因 是 只 满足 了 
条 件 1 而 未 满足 条 件 2。 


针对 上 述 问 题 ， 官 方 文档 上 告诉 我 们 有 3 种 解决 方法 : 


给 你 的 对 象 加 上 get 和 set 方 法 ， 如 果 你 有 权限 的 话 ; 
用 一 个 类 来 包装 原始 对 象 ， 间 接 为 其 提供 get 和 set 方 法 ; 
采用 ValueAnimator， 监 听 动 画 过 程 ， 目 己 实 现 属性 的 改变 。 


针对 上 面 提出 的 三 种 解决 方法 ， 下 面 给 出 具体 的 介绍 。 
1. 给 你 的 对 象 加 上 get 和 set 方 法 ， 如 果 你 有 权限 的 话 


这 个 的 意思 很 好 理解 ， 如 果 你 有 权限 的 话 ， 加 上 get 和 set 束 搞定 
了 。 但 是 很 多 时 候 我 们 没 权 限 去 这 么 做 。 比 如 本 文 开 头 所 提 到 的 问 
题 ， 你 无 法 给 Button 加 上 一 个 合乎 要 求 的 setWidth 方 法 ， 因 为 这 是 
Android SDK 内 部 实现 的 。 这 个 方法 最 简单 ， 但 是 往往 是 不 可 行 的 ， 
这 里 束 不 对 其 进行 更 多 的 分 机 了 。 


2. 用 一 个 类 来 包装 原始 对 象 ， 间 接 为 其 提供 get 和 set 方 法 


这 是 一 个 很 有 用 的 解决 方法 ， 征 笔者 最 喜欢 用 的 ， 因 为 用 起 来 很 
方便 ， 也 很 好 理解 ， 下 面 将 通过 一 个 具体 的 例子 来 介绍 它 。 


private void performAnimate() { 


ViewWrapper wrapper = new ViewWrapper(mButton) ; 


上 述 代 码 在 5s 内 让 Button 的 宽度 增加 到 了 500px， 为 了 达到 这 个 效 
果 ， 我 们 提供 了 ViewWrapper 类 专门 用 于 包装 View， 有 具体 到 本 例 是 包 
装 Button。 然 后 我 们 对 ViewWwrapper 的 width 属性 做 动画 ， 并 且 在 
setWidth 方 法 中 修改 其 内 部 的 target 的 宽度 ， 而 target 实 际 上 就 是 我 们 包 


效 的 Button。 这 样 一 个 间接 属性 动画 

束 搞 定 了 ， 上 壕 代 码 同样 适用 于 一 

个 对 象 的 其 他 属性 。 如 图 7-3 所 示 ， 

很 显然 效 采 达到 了 ， 真 正 实现 了 对 动画 按钮 
宽度 做 动画 。 


图 7-3 ”属性 动画 对 宽度 做 动画 的 效果 


3. 采用 ValueAnimator ， 监 听 动 
画 过 程 ， 自 己 实 现 属性 的 改变 


首先 说 说 什么 是 ValueAnimator，ValueAnimator 本 身 不 作用 于 任何 
对 象 ， 也 就 是 说 直接 使 用 它 没 有 任何 动画 效果 。 它 可 以 对 一 个 值 做 动 
男 ， 然 后 我 们 可 以 监听 其 动画 过 程 ， 在 动画 过 程 中 修改 我 们 的 对 象 的 
属性 值 ， 这 样 也 束 相 当 于 我 们 的 对 象 做 了 动画 。 下 面 用 例子 来 说 明 : 


private void performAnimate(final View target,final int 
start,final int 
end) { 
ValueAnimator valueAnimator = 
ValueAnimator.ofInt(1,100); 
valueAnimator .addUpdateListener (new 
AnimatorUpdateListener() { 
// 持 有 一 个 IntEValuator 对 象 ， 方 便 下 面 估 值 的 时 候 使 用 
private IntEvaluator mEvaluator = new 
IntEvaluator(); 
@Override 
public void onAnimationUpdate(ValueAnimator 
animator) { 


// 获得 当前 动画 的 进度 值 ， 整 型 ，1~100 之 间 


上 述 代 码 的 效果 图 和 采用 ViewWrapper 是 一 样 的 ， 请 参看 图 7-3 > 
关于 这 个 ValueAnimator 要 再 说 一 下 ， 拿 上 面 的 例子 来 说 ， 它 会 在 
5000ms 内 将 一 个 数 从 1 变 到 100， 然 后 动画 的 每 一 帧 会 回调 


onAnimationUpdate 方 法 。 在 这 个 方法 里 ， 我 们 可 以 获取 当前 的 值 (1 
~100) 和 当前 值 所 占 的 比例 ， 我 们 可 以 计算 出 Button 现 在 的 宽度 应 该 
是 多 少 。 比 如 时 间 过 了 一 半 ， 当 前 值 是 50， 比 例 为 0.5， 假 设 Button 的 
起 始 宽度 是 100px， 最 终 宽 度 是 500px， 那 么 Button 增 加 的 视 度 也 应 该 
占 总 增加 宽度 的 一 半 ， 总 增加 宽度 是 500 一 100=400， 所 以 这 个 时 候 
Button 应 该 增加 的 宽度 是 400x0.5=200， 那 么 当前 Button 的 宽度 应 该 为 
初始 宽度 + 增加 宽度 (100+200=300) 。 上 述 计 算 过 程 很 简单 ， 其 实 
它 就 是 整 型 佑 值 器 IntEvaluator 的 内 部 实现 ， 所 以 我 们 不 用 目 己 写 了 ， 
直接 用 吧 。 


7.3.5 ”属性 动画 的 工作 原理 


属性 动画 要 求 动 画作 用 的 对 象 提供 该 属性 的 set 方 法 ， 属 性 动画 根 
据 你 传递 的 该 属性 的 初始 值 和 最 终 值 ， 以 动画 的 效果 多 次 去 调用 set 方 
法 。 每 次 传递 给 set 方 法 的 值 都 不 一 样 ， 确 切 来 说 是 随 着 时 间 的 推移 ， 
所 传递 的 值 越 来 越 接 近 最 终 值 。 如 果 动 画 的 时 候 没 有 传递 初始 值 ， 那 
么 还 要 提供 get 方 法 ， 因 为 系统 要 去 获取 属性 的 初始 值 。 对 于 属性 动画 
来 说 ， 其 动画 过 程 中 所 做 的 就 古 这 么 多 ， 下 面 看 源码 分 析 。 


= A A A DE ye BE 
ObjectAnimator.ofInt(mButton,"width",500).setDuration (5000).start() FF 
始 ， 其 他 动画 都 是 类 似 的 。 先 看 ObjectAnimator 的 start 方 法 : 


public void start() { 
// See if any of the current active/pending animators 
need to be canceled 


AnimationHandler handler = sAnimationHandler.get(); 


上 面 的 代码 别 看 那么 长 ， 其 实 做 的 事情 很 简单 ， 首 移 会 判断 如 采 
当前 动画 、 等 待 的 动画 (Pending) 和 延迟 的 动画 (Delay) 中 有 和 当 
前 动画 相同 的 动画 ， 那 么 束 把 相同 的 动画 给 取消 挥 ， 接 下 来 那 一 段 是 
log， 再 接着 就 调用 了 父 类 的 super.start() 方 法 。 因 为 ObjectAnimator 继 承 
了 ValueAnimator， 所 以 接 下 来 我 们 看 一 下 ValueAnimator 的 Start 方 法 : 


private void start(boolean playBackwards) { 
if (Looper.myLooper() == null) { 
throw new AndroidRuntimeException("Animators 
may only be run on Looper threads"); 
} 
mPlayingBackwards = playBackwards; 


0; 


mCurrentIteration 
mPlayingState = STOPPED; 
mStarted = true; 
mStartedDelay = false; 
mPaused = false; 
updateScaledDuration(); // in case the scale factor has 
changed since creation time 
AnimationHandler animationHandler = 
getOrCreateAnimationHandler(); 
animationHandler .mPendingAnimations.add(this) ; 
if (mStartDelay == 0) { 
// This sets the initial value of the 
animation,prior to actually starting it running 
setCurrentPlayTime(0); 
mPlayingState = STOPPED; 


a UA h A Ea TEA Looper ete o EIRE R 
会 调用 Animation-Handler 的 start 方 法 ， 这 个 AnimationHandler 并 不 是 
Handler， 它 是 一 个 Runnable。 看 一 下 它 的 代码 ， 通 过 代码 我 们 发 现 ， 
很 快 就 调 到 了 JNI 层 ， 不 过 JNI 层 最 终 还 是 要 调 回 来 的 。 它 的 run 方 法 会 
被 调用 ， 这 个 Runnable 涉 及 和 底层 的 交互 ， 我 们 就 忽略 这 部 分 ， 直 接 
看 重点 : ValueAnimator 中 的 doAnimationFrame 方 法 ， 如 下 所 示 。 


注意 到 上 述 代 码 末 尾 调 用 了 animationFrame 方 法 ， 而 
animationFrame 内 部 调用 了 animateValue， 下 面 看 animateValue 的 代码 : 


void animateValue(float fraction) { 

fraction = mInterpolator.getInterpolation(fraction); 

mCurrentFraction = fraction; 

int numValues = mValues.length; 

for (int i = 0; i < numValues; ++i) { 
mValues[i].calculateValue(fraction); 

} 

if (mUpdateListeners != null) { 
int numListeners = mUpdateListeners.size(); 


for (int i = 0; i < numListeners; ++1) { 


mUpdateListeners.get(1).onAnimationUpdate(this) ; 


i 


上 述 代码 中 的 calculatevalue 方 法 就 是 计算 每 帧 动画 所 对 应 的 属性 
的 值 ， 下 面 着 重 看 一 下 到 底 是 在 哪里 调用 属性 的 get 和 set 方 法 的 ， 毕 疯 
这 个 才 是 我 们 最 关心 的 。 


在 初始 化 的 时 候 ， 如 果 属 性 的 初始 值 没 有 提供 ， 则 get 方 法 将 会 被 
调用 ， 请 看 Property-ValuesHolder 的 setupValue 方 法 ， 可 以 发 现 get 方 法 
是 通过 反映 来 调用 的 ， 如 下 所 示 。 


private void setupValue(Object target,Keyframe kf) { 
if (mProperty != null) { 
Object value = 


convertBack(mProperty.get(target) ); 


当 动 画 的 下 一 帧 到 来 的 时 候 ， PropertyValuesHolder 中 的 
setAnimatedvValue 方 法 会 将 新 的 属性 值 设置 给 对 象 ， 调 用 其 set 方 法 。 从 
下 面 的 源码 可 以 看 出 ，set 方 法 也 是 通过 反射 来 调用 的 : 


void setAnimatedValue(Object target) { 
if (mProperty != null) { 
mProperty.set(target, getAnimatedValue()); 
} 
if (mSetter != null) { 
try { 
mTmpValueArray[0] = getAnimatedValue(); 
mSetter.invoke(target, mTmpValueArray); 


} catch (InvocationTargetException e) { 


Log.e("PropertyValuesHolder",e.toString()); 


} catch (IllegalAccessException e) { 


Log.e("PropertyValuesHolder",e.toString()); 
} 


74 使 用 动画 的 注意 事项 


通过 动画 可 以 实现 一 些 比较 绚丽 的 效果 ， 但 是 在 使 用 过 程 中 ， 也 
需要 注意 一 些 事情 ， 主 要 分 为 下 面 几 类 。 


1. OOM 问 题 


这 个 问题 主要 出 现在 巾 动 画 中 ， 当 图 片 数量 较 多 且 图 片 较 大 时 束 
极 易 出 现 OOM， 这 个 在 实际 的 开发 中 要 尤其 注意 ， 尽 量 避 免 使 用 帧 动 


El 


2. AFR 


在 属性 动画 中 有 一 类 无 限 循环 的 动画 ， 这 类 动画 需要 在 Activity 退 
出 时 及 时 停止 ， 否 则 将 导致 Activity 无 法 释放 从 而 造成 内 存 泄 露 ， 通 过 
验证 后 发 现 View 动 画 并 不 存在 此 问题 。 


3. 兼容 性 问题 


动画 在 3.0 以 下 的 系统 上 有 兼容 性 问题 ， 在 某 些 特殊 场景 可 能 无 法 
正常 工作 ， 因 此 要 做 好 适 配 工作 > 


4. View 动 画 的 问题 


View 动 画 是 对 View 的 影像 做 动画 ， 并 不 是 真正 地 改变 View 的 状 
态 ， 因 此 有 时 候 会 出 现 动画 完成 后 View 无 法 隐藏 的 现象 ， 即 
setVisibility(View. GONE) 失效 了 ， 这 个 时 候 只 要 调用 
view.clearAnimation0) 清 除 View 动 画 即 可 解决 此 问题 。 


>. 不 要 使 用 px 


在 进行 动画 的 过 程 中 ， 要 尽量 使 用 dp， 使 用 px 会 导致 在 不 同 的 设 
备 上 有 不 同 的 效果 。 


6. 动画 元 素 的 交互 


将 view 移 动 (FR) 后 ， 在 Android 3.0 以 前 的 系统 上 ， 不 管 是 
View 动 画 还 是 属性 动画 ， 新 位 置 均 无 法 触发 单 击 事件 ， 同 时 ， 老 位 置 
仍然 可 以 触发 单 击 事件 。 尽 管 View 已 经 在 视觉 上 不 存在 了 ， 将 View 移 


回 原 位 置 以 后 ， 原 位 置 的 单 击 事件 继续 生效 。 从 3.0 开 始 ， 属 性 动画 的 
单 击 事件 触发 位 置 为 移动 后 的 位 置 ， 但 是 View 动 画 仍然 在 原 位 置 。 


7. 硬件 加 速 


使 用 动画 的 过 程 中 ， 建 议 开局 硬件 加 速 ， 这 样 会 提高 动画 的 流畅 
TE» 


第 8 章 ”理解 Window 和 


WindowManager 


Window 表 示 一 个 窗口 的 概念 ， 在 日 常 开发 中 直接 接触 window 的 
机 会 并 不 多 ， 但 是 在 某 些 特殊 时 候 我 们 需要 在 蝎 面 上 显示 一 个 类 似 悬 
浮 窒 的 东西 ， 那 么 这 种 效果 丈 需 要 用 到 Window 来 实现 。Window 有 是 一 
个 抽象 类 ， 它 的 具体 实现 是 PhoneWindow。 创建 一 个 Window 是 很 简单 
的 事 ， 只 需要 通过 WindowManager 即 可 完成 。WindowManager 是 外 界 
访问 Window 的 入 口 ，Window 的 具体 实现 位 于 WindowManagerService 
中 ，WindowManager 和 Window-ManagerService 的 交互 是 一 个 IPC 过 
程 。Android 中 所 有 的 视图 都 是 通过 Window 来 呈现 的 ,不管 是 
Activity、Dialog 还 是 Toast， 它 们 的 视图 实际 上 都 是 附加 在 Window 上 
的 ， 因 此 Window 实 际 是 View 的 直接 管理 者 。 从 第 4 章 中 所 讲述 的 View 
的 事件 分 发 机 制 也 可 以 知道 ， 单 击 事件 由 Window 传 递 给 DecorView， 
然后 再 由 DecorView 传 递 给 我 们 的 View， 束 连 Activity 的 设置 视图 的 方 
法 setContentView 在 底层 也 是 通过 Window 来 完成 的 。 


8.1 Window 和 WindowManager 


为 了 分 析 Window 的 工作 机 制 ， 我 们 需要 先 了 解 如 何 使 用 
WindowManager 添 加 一 个 Window。 下 面 的 代码 演示 了 通过 
WindowManager 添 加 Window 的 过 程 ， 是 不 是 很 简单 呢 ? 


mFloatingButton = new Button(this); 
mFloatingButton.setText("button"); 


mLayoutParams = new WindowManager .LayoutParams( 


LayoutParams.WRAP_CONTENT, LayoutParams .WRAP_CONTENT, 0, O, 
PixelFormat . TRANSPARENT); 
mLayoutParams.flags = LayoutParams.FLAG_NOT_TOUCH_MODAL 
| LayoutParams.FLAG_NOT_FOCUSABLE 
| LayoutParams. FLAG_SHOW_WHEN_LOCKED 
mLayoutParams.gravity = Gravity.LEFT | Gravity.TOP; 
mLayoutParams.x = 100; 
mLayoutParams.y = 300; 


mWindowManager .addView(mFloatingButton, mLayoutParams ) ; 


上 述 代 码 可 以 将 一 个 Button 添 加 到 屏幕 坐标 为 《100，300) 的 位 
置 上 。WindowManager. LayoutParams 中 的 flags 和 type 这 两 个 参数 比较 
重要 ， 下 面 对 其 进行 说 明 。 


Flags 参 数 表示 Window 的 属性 ， 它 有 很 多 选项 ， 通 过 这 些 选 项 可 
以 控制 Window 的 显示 特性 ， 这 里 主要 介绍 几 个 比较 前 用 的 选项 ， 剩 下 
的 请 查看 官方 文档 。 


FLAG_NOT_FOCUSABLE 


表示 Window 不 需要 获取 焦点 ， 也 不 需要 接收 各 种 输入 事件 ， 此 标 
记 会 同时 启用 FLAG_NOT _TOUCH MODAL ， 最 终 事件 会 直接 传递 给 
下 层 的 具有 焦点 的 Window ° 


FLAG_NOT_TOUCH_MODAL 


在 此 模式 下 ， 系 统 会 将 当前 Window 区 域 以 外 的 单 击 事件 传递 给 底 
层 的 Window， 当 前 Window 区 域 以 内 的 单 击 事件 则 目 己 处 理 。 这 个 标 
记 很 重要 ， 一 般 来 说 都 需要 开局 此 标记 ， 人 否则 其 他 Window 将 无 法 收 到 
单 击 事件 。 


FLAG_SHOW_WHEN_LOCKED 
开启 此 模式 可 以 让 Window 显 示 在 锁 屏 的 界面 上 。 


Type 参数 表示 Window 的 类 型 ，Window 有 三 种 类 型 ， 分 别 是 应 用 
Window、 子 Window 和 系统 Window。 应 用 类 Window 对 应 着 一 个 
Activity。 子 Window 不 能 单独 存在 ， 它 需要 附属 在 特定 的 父 Window 之 
中 ， 比 如 常见 的 一 些 Dialog 束 是 一 个 子 Window。 系统 Window 是 需要 声 
明 权 限 在 能 创建 的 Window， 比 如 Toast 和 系统 状态 栏 这 些 都 是 系统 
Window ° 


Window 是 分 层 的 ， 每 个 window 都 有 对 应 的 z-ordered， 层 级 大 的 
会 覆盖 在 层级 小 的 Window 的 上 面 ， 这 和 HTML 中 的 z-index 的 概念 是 完 
全 一 致 的 。 在 三 类 Window 中 ， 应 用 Window 的 层级 范围 是 1~99， 子 
Window 的 层级 范围 是 1000 全 1999， 系 统 Window 的 层级 范围 是 2000~~ 
2999， 这 些 层级 范围 对 应 着 WindowManager.LayoutParams 的 type 参 
数 。 如 果 想 要 Window 位 于 所 有 Window 的 最 顶层 ， 那 么 采用 较 大 的 层 
级 即 可 。 很 显然 系统 Window 的 层级 是 最 大 的 ， 而 且 系 统 层 级 有 很 多 
值 ， 一 般 我 们 可 以 选用 TYPE SYSTEM OVERLAY 或 者 
TYPE_SYSTEM_ERROR, ， 如 宁 采 用 TYPE_SYSTEM_ERROR H fe 
要 为 type 人 参数 指定 这 个 层级 即 可 : mLayoutParams.type = 


LayoutParams. TYPE_SYSTEM_ERROR; 同时 声明 权限 : <uses- 
permission 

android:name="android.permission.SYSTEM_ALERT_WINDOW" /> > 
为 系统 类 型 的 Window 是 需要 检查 权限 的 ， 如 采 不 在 AndroidManifest 中 
使 用 相应 的 权限 ， 那 么 创建 Window 的 时 候 就 会 报错 ， 错 误 如 下 所 示 。 


E/AndroidRuntime(8071): Caused by: 
android.view.WindowManager$BadToken- Exception: Unable to add 
window android. view. ViewRoot Imp1$w@42882fe8 -- permission 


denied for this window type 

E/AndroidRuntime( 8071): at 
android.view.ViewRootImpl.setView(ViewRootImpl. java:677) 

E/AndroidRuntime( 8071): at 
android.view.WindowManagerImpl.addView(Window- 
ManagerImpl.java:326) 

E/AndroidRuntime (8071): at 
android.view.wWindowManagerImpl.addView(Window- 
ManagerImpl.java:224) 

E/AndroidRuntime (8071): at 
android. view.windowManagerImpl$CompatMode - 

Wrapper .addView(WindowManagerImpl.java:149) 

E/AndroidRuntime (8071): at 
android. view.window$LocalwWindowManager..addView(Window.java:558) 

E/AndroidRuntime (8071): at 
com.ryg.chapter_8.TestActivity.onButtonClick(TestActivity.java: 
60) 

E/AndroidRuntime(8071): ... 14 more 


W/ActivityManager( 514): Force finishing activity 


com.ryg.chapter_8/.TestActivity 


WindowManager 所 提供 的 功能 很 简单 ， 常 用 的 只 有 三 个 方法 ， 即 
添加 View、 更 新 View 和 删除 View， 这 三 个 方法 定义 在 ViewManager 
中 ， 而 WindowManager 继 承 了 ViewManager ° 


public interface ViewManager 
i 
public void addView(View view, ViewGroup.LayoutParams 
params); 
public void updateViewLayout (View 
view, ViewGroup.LayoutParams params); 
public void removeView(View view); 


i 


对 开发 者 来 说 ，WindowManager 常 用 的 就 只 有 这 三 个 功能 而 已 ， 
但 是 这 三 个 功能 已 经 足够 我 们 使 用 了 。 它 可 以 创建 一 个 Window 并 问 其 
添加 View， 还 可 以 更 新 Window 中 的 View， 男 外 如 采 想 要 删除 一 个 
Window ， 那 么 只 需要 删除 它 里 面 的 View 即 可 。 由 此 来 看 ， 
WindowManager 操 作 Window 的 过 程 更 像 是 在 操作 Window 中 的 View ° 
我 们 时 第 见 到 那 种 可 以 拖 动 的 Window 歼 果 ， 其 实 是 很 好 实现 的 ， 只 需 
要 根据 手指 的 位 置 来 设 定 LayoutParams 中 的 x 和 y 的 值 即 可 改变 Window 
的 mE. 首先 给 View % $  onTouchListener 
mFloatingButton.setOnTouchListener(this)。 然 后 在 onTouch 方 法 中 不 断 
更 新 View 的 位 置 即 可 : 


public boolean onTouch(View v,MotionEvent event) { 
int rawX = (int) event.getRawX(); 
int rawY = (int) event.getRawY(); 
switch (event.getAction()) { 
case MotionEvent.ACTION_MOVE: { 
mLayoutParams.x = rawX; 


mLayoutParams.y = rawY; 


mwWindowManager .updateViewLayout (mFloatingButton, mLayoutParams); 


break; 
} 
default: 
break; 
} 
return false; 
} 
8.2 ” Window 的 内 部 机 制 
Window 是 一 个 抽象 的 概念 ， 每 一 个 Window 都 对 应 着 一 个 View 和 


一 个 ViewRootImpl，Window 和 View 通 过 ViewRootImpl 来 建立 联系 ， 因 
此 Window 并 不 是 实际 存在 的 ， 它 是 以 View 的 形式 存在 。 这 点 从 
WindowManager 的 定义 也 可 以 看 出 ， 它 提供 的 三 个 接口 方法 addView ` 

updateViewLayout 以 及 removeView 都 是 针对 View 的 ， 这 说 明 View 才 是 
Window 存 在 的 实体 。 在 实际 使 用 中 无 法 直接 访问 Window， 对 Window 


的 访问 必须 通过 WindowManager。 为 了 分 析 Window 的 内 部 机 制 ， 
从 Window 的 添加 、 删 除 以 及 更 新 说 起 。 


8.2.1 Window 的 添加 过 程 


Window 的 添加 过 程 需 过 WindowManager 的 addView 来 实现 ， 
WindowManager 是 一 个 接口 ， 它 的 真正 实现 是 WindowManagerImpl 
类 。 在 WindowManagerImpl 中 Window 的 三 大 操作 的 实现 如 下 : 


@Override 
public void addView(View view, ViewGroup.LayoutParams 
params) { 
mGlobal.addView( view, params, mDisplay,mParentWindow) ; 
} 
@Override 
public void updateViewLayout (View 
view, ViewGroup.LayoutParams params) { 
mGlobal.updateViewLayout (view, params); 
} 
@Override 
public void removeView(View view) { 


mGlobal.removeView(view, false); 


可 以 发 现 ，WindowManagerImpl 并 没有 直接 实现 Window 的 三 大 操 
作 ， 而 是 全 部 区 给 了 WindowManagerGlobal 来 处 理 ， 
WindowManagerGlobal 以 工厂 的 形式 同 外 提供 目 己 的 实例 ， 在 


WindowManagerGlobal + @ W F — Be ft #4 : private final 
Window ManagerGlobal mGlobal = 
WindowManagerGlobal.getInstance0。WindowManagerImpl 这 种 工作 模 
式 是 典型 的 桥接 模式 ， 将 所 有 的 操作 全 部 委托 给 
WindowManagerGlobal 来 实现 。WindowManager-Global 的 addView 方 法 
主要 分 为 如 下 几 步 。 


1. 检查 参数 是 否 合法 ， 如 果 是 子 window 那 么 还 需要 调整 一 些 布 
局 参数 


if (view == null) { 
throw new IllegalArgumentException("view must not be 
null"); 
} 
if (display == null) { 
throw new IllegalArgumentException("display must not be 
null"); 
$ 
if (!(params instanceof WindowManager .LayoutParams)) { 
throw new IllegalArgumentException("Params must be 
WindowManager.LayoutParams"); 
} 
final WindowManager .LayoutParams wparams = 
(WindowManager .LayoutParams ) params; 
if (parentWindow != null) { 


parentWindow.adjustLayoutParamsForSubWindow(wparams ) ; 


2. 创建 ViewRootImpl 并 将 View 添 加 到 列表 中 
在 WindowManagerGlobal 内 部 有 如 下 几 个 列表 比较 重要 : 


private final ArrayList<View> mViews = new ArrayList<View> 
O; 

private final ArrayList<ViewRootImpl> mRoots = new 

ArrayList 

<ViewRootImpl>(); 

private final ArrayList<WindowManager .LayoutParams> 

mParams = 

new ArrayList<WindowManager .LayoutParams>(); 

private final ArraySet<View> mDyingViews = new 


ArraySet<View>(); 


在 上 面 的 声明 中 ，mViews 存 储 的 是 所 有 Window 所 对 应 的 View， 
mRoots 存 储 的 是 所 有 Window 所 对 应 的 ViewRootImpl，mParams 存 储 的 
是 所 有 Window 所 对 应 的 布局 参数 ， 而 mDyingViews 则 存储 了 那些 正在 
被 删除 的 View 对 象 ， 或 者 说 是 那些 已 经 调用 removeView 方 法 但 是 删除 
操作 还 未 完成 的 Window 对 象 。 在 addView 中 通过 如 下 方式 将 Window 的 
一 系列 对 象 添 加 到 列表 中 : 


root = new ViewRootImpl(view.getContext(),display); 
view.setLayoutParams(wparams ) ; 

mViews.add(view) ; 

mRoots.add( root); 


mParams.add(wparams); 


3. 通过 ViewRootImpl 来 更 新 界面 并 完成 window 的 添加 过 程 


这 个 步骤 由 ViewRootImpl 的 setView 方 法 来 完成 ， 从 第 4 章 可 以 知 
道 ，View 的 绘制 由 ViewRootImpl 来 完成 的 ， 这 里 当然 也 不 例 
外 ， 在 setView 内 部 会 通过 requestLayout 来 完成 异步 刷新 请 求 。 在 下 面 
的 代码 中 ，scheduleTraversals 实 际 是 View 绘 制 的 入 口 : 


public void requestLayout() { 
if (!mHandlingLayoutInLayoutRequest) { 
checkThread(); 
mLayoutRequested = true; 


scheduleTraversals(); 


接着 会 通过 WindowSession 最 终 来 完成 Window 的 添加 过 程 。 在 下 
面 的 代码 中 ，mWindowSession 的 类 型 是 ITWindowSession ， 它 是 一 个 
Binder 对 象 ， 真 正 的 实现 类 是 Session， 也 就 是 Window 的 添加 过 程 是 一 
次 IPC 调 用 。 


try { 
mOrigWindowType = mWindowAttributes.type; 


mAttachInfo.mRecomputeGlobalAttributes = true; 
collectViewAttributes(); 
res = 


mwWindowSession.addToDisplay(mwWindow, mSeq, mwindowAttributes, 


getHostVisibility(),mDisplay.getDisplayld(), 


在 Session 内 部 会 通过 WindowManagerService 来 实现 Window 的 添 


加 ， 代 码 如 下 所 示 。 


UNE — A, Window 4s IT SK 40 24 WindowManagerService 4h 
理 了 ， 在 Window-ManagerService 内 部 会 为 每 一 个 应 用 保留 一 个 单独 的 
Session ° AK Windowf£ Wino we Manne cpa eel HY, 
本 间 不 对 其 进行 进一步 的 分 析 ， 这 是 因为 到 此 为 止 我 们 对 Window 的 添 
加 这 一 流程 已 经 清楚 了 ， 而 在 WindowManagerService 内 部 主要 是 代码 
细 方 ， 深 入 进去 没有 太 大 的 意义 ， 读 者 可 以 目 行 阅读 源码 或 者 参考 相 
天 的 源码 分 析 书 籍 ， 本 书 对 源码 的 分 析 侧 重 的 是 整体 流程 ， 会 尽量 避 
人 免 出 现 深入 代码 逻 EA BÆ > 


8.2.2 Window 的 删除 过 程 


Window 的 删除 过 程 和 添加 过 程 一 样 ， 都 是 先 通 过 
WindowManagerImpl 后 ， 再 进一步 通过 WindowManagerGlobal 来 实现 
的 。 下 面 是 WindowManagerGlobal 的 removeView 的 实现 : 


public void removeView(View view,boolean immediate) { 
if (view == null) { 
throw new IllegalArgumentException("view must 
not be null"); 

i 

synchronized (mLock) { 
int index = findViewLocked(view, true); 
View curView = mRoots.get(index).getView(); 
removeViewLocked(index, immediate); 
if (curView == view) { 


return; 


removeView 的 逻辑 很 清晰 ， 首 先 通过 findViewLocked 来 查找 待 删 
除 的 View 的 索引 ， 这 个 查找 过 程 束 是 建立 的 数组 遍历 ， 然 后 再 调用 
removeViewLocked 来 做 进一步 的 删除 ， 如 下 所 示 。 


if (deferred) { 


mDyingViews.add(view) ; 


removeViewLocked 是 通过 ViewRootImpl 来 完成 删除 操作 的 。 在 
WindowManager 中 提供 了 两 种 删除 接口 removeView 和 
removeViewImmediate ， 它 们 分 别 表示 异步 删除 和 同步 删除 ， 其 中 
removeViewImmediate 使 用 起 来 需要 特别 注意 ， 一 般 来 说 不 需要 使 用 此 
方法 来 删除 Window 以 免 发 生意 外 的 错误 。 这 里 主要 说 异步 删除 的 情 
况 ， 具 体 的 删除 操作 由 ViewRoot-Impl 的 die 方 法 来 完成 。 在 异步 删除 的 
情况 下 ，die 方 法 只 是 发 送 了 一 个 请 求 删 除 的 消息 后 惑 立 刻 返 回 了 ， 这 
个 时 候 View 并 没有 完成 删除 操作 ， 所 以 最 后 会 将 其 添加 到 
mDyingViews 中 , mDyingViews 表示 待 删除 的 View 列 表 。 
ViewRootImpl 的 die 方 法 如 下 所 示 。 


boolean die(boolean immediate) { 
// Make sure we do execute immediately if we are in the 
middle of a traversal or the damage 
// done by dispatchDetachedFromWindow will cause havoc 
on return. 
if (immediate && !mIsInTraversal) { 
doDie(); 
return false; 
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if (!mIsDrawing) { 


destroyHardwareRenderer(); 
} else { 
Log.e(TAG, "Attempting to destroy the window 
while drawing!\n" + 
" window=" + this + ",title=" + 
mwWindowAttributes. 
getTitle()); 
} 
mHandler .sendEmptyMessage(MSG_DIE); 
return true; 


} 


fedie TIAA BBR E TAFT, MASA, ALARA 
送 一 个 MSG_DIE 的 消息 ，ViewRootImpl 中 的 Handler 会 处 理 此 消息 并 调 
用 doDie 方 法 ， ATE (立即 删除 ，， 那 么 就 不 发 消息 直接 调 
用 doDie 方 法 ， 这 束 是 这 两 种 删除 方式 的 区 别 。 在 doDie 内 部 会 调用 
dispatchDetachedFromWindow 方 法， 真正 删除 View 的 逻辑 在 
dispatchDetachedFromWindow FF 法 的 内 部 实 He 
dispatchDetachedFromWindow 方 法 主要 做 四 件 事 : 


(1) 垃圾 回收 相关 的 工作 ， 比 如 清除 数据 和 消息 、 移 除 回 调 。 


( 2 ) 38 IE Session 的 remove 方法 Hl BR Window : 
mWindowSession.remove(mWindow)， 这 同样 是 一 个 IPC 过 程 ， 最 终 会 
调用 WindowManagerService 的 removeWindow 方 法 。 


(3) 调用 View 的 dispatchDetachedFromWindow 方 法 ， 在 内 部 会 调 
用 View 的 onDetached-FromWindow() pl 及 


onDetachedFromWindowInternal() ° X} F onDetachedFromWindow K 2 
ESPE, S View Window HRR, AAT ARR, AT 
A E LIE, ERROR E F ERTE 


HE o 
于 


(4) 调用 WindowManagerGlobal 的 doRemoveView 方 法 刷新 数 
据 ， 包 括 mRoots、mpParams 以 及 mDyingViews， 需 要 将 当前 Window 所 
关联 的 这 三 类 对 象 从 列表 中 删除 。 


8.2.3 ”Window 的 更 新 过 程 


到 这 里 ，Window 的 删除 过 程 已 经 分 析 完 毕 了 ， 下 面 分 析 Window 
的 更 新 过 程 ， 还 是 要 看 WindowManagerGlobal 的 E 方 
法 ， 如 下 所 示 。 


public void updateViewLayout (View 
view, ViewGroup.LayoutParams params) { 
if (view == null) { 
throw new IllegalArgumentException("view must 
not be null"); 
} 
if (!(params instanceof WindowManager .LayoutParams)) { 
throw new IllegalArgumentException("Params must 
be WindowManager.LayoutParams"); 
} 
final WindowManager.LayoutParams wparams = 


(WindowManager .Layout-Params)params; 


view.setLayoutParams(wparams ) ; 

synchronized (mLock) { 
int index = findViewLocked(view, true); 
ViewRootImpl root = mRoots.get(index); 
mParams.remove(index); 
mParams.add(index,wparams); 


root.setLayoutParams(wparams, false); 


} 


update ViewLayout Ù YE (KW SIs wt, BAER 
View 的 LayoutParams 并 替换 掉 老 的 LayoutParams ， 接 着 再 更 新 
ViewRootImpl 中 的 LayoutParams ， 这 一 步 是 通过 ViewRootImpl 的 
setLayoutParams 方法 来 实现 的 。 在 ViewRootImpl 中 会 通过 
scheduleTraversals 方 法 来 对 View 重 新 布局 ， 包 括 测量 、 布 局 、 重 绘 这 
三 个 过 程 。 除 了 View 本 二 的 重 绘 以 外 ，ViewRootImpl 还 会 通过 
WindowSession 来 更 新 Window 的 视图 ， 这 个 过 程 最 终 是 由 
WindowManagerService 的 relayoutWindow0 来 具体 实现 的 ， 它 同样 是 一 
个 IPC 过 程 。 


8.3 Window 的 创建 过 程 


过 上 面 的 分 析 可 以 看 出 ，View 是 Android 中 的 视图 的 呈现 方式 ， 
但 是 ld 它 必 须 附 着 在 me ee ee 
因此 有 视图 的 地 方丈 有 Window。 哪 些 地 方 有 视图 昵 ? 这 个 读者 都 比较 
清楚 ，Android 中 可 以 提供 视图 的 地 方 有 Activity、Dialog、Toast， 除 此 


之 外 ， 还 有 一 些 依 托 Window 而 实现 的 视图 ， 比 如 PopUpWwindow、 沫 
单 ， 它 们 也 是 视图 ， 有 视图 的 地 方丈 有 Window It Activity ` 
Dialog、Toast 等 视图 都 对 应 着 一 个 Window。 本 节 将 分 析 这 些 视 图 元 素 
中 的 Window 的 创建 过 程 ， 通 过 本 节 可 以 使 读者 进一步 加 深 对 Window 
的 理解 。 


8.3.1 Activity 的 Window 创 建 过 程 


要 分 析 Activity 中 的 Window 的 创建 过 N da 
过 程 ， 详 细 的 过 程 会 在 第 9 章 进行 介绍 ， 这 里 先 大 概 了 解 即 可 。 
Activity 的 启动 过 程 很 复杂 ， 最 终 会 由 ActivityThread 中 的 
performLaunchActivity() 来 完成 整个 启动 过 程 ， 在 这 个 方法 内 部 会 通过 
类 加 载 絮 创建 Activity 的 实例 对 象 ， 并 调用 其 attach 方 法 为 其 关联 运行 
过 程 中 所 依赖 的 一 系列 上 下 文 环境 变量 ， 代 码 如 下 所 示 。 


java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); 
activity = mInstrumentation.newActivity( 


cl,component..getClassName(),r.intent); 


if (activity != null) { 
Context appContext = 
createBaseContextForActivity(r,activity); 
CharSequence title = 
r.activityInfo.loadLabel(appContext.getPackage-Manager()); 
Configuration config = new 


Configuration(mCompatConfiguration); 


if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity 


+ r.activityInfo.name + " with config " 


+ config); 
activity.attach(appContext, this, getInstrumentation(),r.token, 
r.ident,app,r.intent,r.activityInfo, title,r.parent, 


r.embeddedID, r.lastNonConfigurationInstances, config, 


r.voicelnteractor); 


在 Activity 的 attach 方 法 里 ， 系 统 会 创建 Activity 所 属 的 Window 对 象 
并 为 其 设置 回调 接口 ，Window 对 象 的 创建 是 通过 PolicyManager 的 
makeNewWindow 方 法 实现 的 。 由 于 Activity 实 现 了 Window 的 Callback 
接口 ， 因 此 当 Window 接 收 到 外 界 的 状态 改变 时 就 会 回调 Activity 的 方 
法 。Callback 接 口中 的 方法 很 多 ,但 是 有 几 个 却 是 我 们 都 非常 熟悉 
的 ， FE 如 onAttachedToWindow ` onDetachedFromWindow ` 
dispatchTouchEvent， 等 等 ， 代 码 如 下 所 示 。 


mwindow = PolicyManager .makeNewWindow( this); 
mWindow.setCallback(this); 
mWindow.setOnWindowDismissedCallback(this); 


mWindow.getLayoutInflater().setPrivateFactory(this); 


if (info.softInputMode ! 


WindowManager .LayoutParams.SOFT_INPUT_STATE_ UNSPECIFIED) { 
mwWindow.setSoftInputMode(info.softInputMode); 
} 
if (info.uiOptions != 0) { 


mwindow.setUiOptions(info.uiOptions); 


从 上 面 的 分 析 可 以 看 出 ，Activity 的 Window 是 通过 PolicyManager 
的 一 个 工厂 方法 来 创建 的 ， 但 是 从 PolicyManager 的 类 名 可 以 看 出 ， 它 
不 是 一 个 普通 的 类 ， 它 是 一 个 策略 类 。PolicyManager 中 实现 的 几 个 工 
厂 方法 全 部 在 策略 接口 IPolicy 中 声明 了 ，IPolicy 的 定义 如 下 : 


public interface IPolicy { 
public Window makeNewWindow(Context context); 
public LayoutInflater makeNewLayoutInflater (Context 
context); 
public WindowManagerPolicy makeNewWindowManager (); 
public FallbackEventHandler 
makeNewFallbackEventHandler (Context 


context); 


在 实际 的 调用 中 ，PolicyManager 的 真正 实现 是 Policy 类 ，Policy 类 
中 的 makeNewWindow 方 法 的 实现 如 下 ， 由 此 可 以 发 现 ，Window 的 具 
体 实现 的 确 是 PhoneWindow ° 


public Window makeNewWindow(Context context) { 


return new PhoneWindow(context); 


} 


天 于 策略 类 PolicyManager 是 如 何 关 联 到 Policy 上 面 的 ， 这 个 无 法 
从 源码 中 的 调用 关系 来 得 出 ， 这 里 猜测 可 能 是 由 编译 环节 动态 控制 
的 。 到 这 里 Window 已 经 创建 完成 了 ， 下 面 分 析 Activity 的 视图 是 怎么 
附属 在 Window 上 的 。 由 于 Activity 的 视图 由 setContentView 方 法 提供 ， 
我 们 只 需要 看 setContentView 方 法 的 实现 即 可 。 


public void setContentView(int layoutResID) { 
getWindow().setContentView(layoutResID); 
initwindowDecorActionBar(); 


} 


从 Activity 的 setContentView 的 实现 可 以 看 出 ，Activity 将 具体 实现 
区 给 了 Window 处 理 ， 而 Window 的 具体 实现 是 PhoneWindow， 所 以 只 
需要 看 PhoneWindow 的 相关 逻辑 即 可 。PhoneWindow 的 setContentView 
方法 大 致 遵 循 如 下 几 个 步 又。 


1. 如 果 没 有 DecorView， 那 么 就 创建 它 


DecorView 是 一 个 FrameLayout， 在 第 4 章 已 经 做 了 初步 的 介绍 ， 这 
里 再 简单 说 一 下 。DecorView 是 Activity 中 的 顶级 View， 一 般 来 说 它 的 
内 部 包含 标题 栏 和 内 部 栏 ， 但 是 这 个 会 随 着 主题 的 变换 而 发 生 改 变 。 
不 管 怎 么 样 ， 内 容 栏 是 一 定 要 存在 的 ， 并 且 内 容 来 具体 固定 的 id， 那 
re “content”, EHI Kid&android.R.id.content ° DecorViewNR ET 
程 由 installDecor 方 法 来 完成 ， 在 方法 内 部 会 通过 generateDecor 方 法 来 
直 授 创建 DecorView， 这 个 时 候 DecorView 还 只 是 一 个 空 日 的 


FrameLayout: 


protected DecorView generateDecor() { 


return new DecorView(getContext(),-1); 


为 了 初始 化 DecorView 的 结构 ，PhoneWindow 还 需要 通过 
generateLayout 方 法 来 加 载 具 体 的 dl 局 文件 到 DecorView 中 ， 有 具体 的 布 
局 文件 和 系统 版 本 以 及 主题 有 关 ， 这 个 过 程 如 下 所 示 。 


View in = mLayoutInflater.inflate(layoutResource, null); 
decor .addView(in, new 
ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT)); 
mContentRoot = (ViewGroup) in; 
ViewGroup contentParent = 


(ViewGroup)findViewById(ID_ANDROID_CONTENT); 


其 中 ID ANDROID CONTENT 的 定义 如 下 ， 这 个 这 所 对 应 的 


ViewGroup 就 是 mContentParent: 


public static final int ID_ANDROID_CONTENT = 


com.android.internal.R.id.content 
2. 将 View 添 加 到 DecorView 的 mContentParent 中 


过 程 束 比较 简单 了 ， 由 于 在 步 又 1 中 已 经 创建 并 初始 化 了 
DecorView, ， 因 此 这 一 步 直接 将 Activity 的 视图 添加 到 DecorView 的 
mContentParent 中 即 可 
mLayoutInflater.inflate(layoutResID,mContentParent) ° 到 此 为 上， 
Activity 的 布局 文件 已 经 添加 到 Decorview 里 面 了 ， 由 此 2 以 理解 
Activity 的 setContentView 这 个 方法 的 来 历 了 。 不 知道 读者 是 否 曾经 怀 


疑 过 : 为 什么 不 叫 setView 呢 ? 它 明 明 是 给 Activity 设 置 视 图 的 啊 ! 从 这 
里 来 看 ， 它 的 确 不 适合 叫 setView， 因 为 Activity 的 布局 文件 只 是 被 添加 
到 DecorView 的 mContentParent 中 ， 因 此 叫 setContentView 更 加 准确 。 


3. 回调 Activity 的 onContentChanged 方 法 通知 Activity 视 图 已 经 发 
生 改 变 


这 个 过 程 就 更 简单 了 ， 由 于 Activity 实 现 了 Window 的 Callback 接 
口 ， 这 里 表示 Activity 的 布局 文件 已 经 被 添加 到 DecorView 的 
mContentParent 中 了 ， 于 是 需要 通知 Activity， 使 其 可 以 做 相应 的 处 
HE o Activity 的 memece 法 是 个 空 实现 ， 我 们 可 以 在 子 
Activity 中 处 理 这 个 回调 。 这 个 过 程 的 代码 如 下 所 示 。 


final Callback cb = getCallback(); 
if (cb != null && !isDestroyed()) { 


cb.onContentChanged(); 


经 过 了 上 面 的 三 个 步骤 ， 到 这 里 为 止 DecorView 已 经 被 创建 并 初 
台 化 完毕 ，Activity 的 布局 文件 也 已 经 成 功 添加 到 了 DecorView 的 
Cae 但 是 这 个 时 候 DecorView 还 没有 被 WindowManager 
正式 添加 到 Window 中 。 这 里 需要 正确 理解 Window 的 概念 ，Window 更 
多 表示 的 是 一 种 抽象 的 功能 集合 ， 虽 然 说 早 在 Activity 的 attach 方 法 中 
Window 束 已 经 被 创建 了 ， 但 是 这 个 时 候 由 于 DecorView 并 没有 被 
WindowManager 识 别 ， 所 以 这 个 时 候 的 Window 无 法 提供 具体 功能 ， 因 
为 它 还 无 法 接收 外 界 的 输入 信息 。 在 TO EN 
handleResumeActivity WWE, ft Val A Activity onResume 77 X, 
接着 会 调用 Activity HJ makeVisible(), 1E 7 £ makeVisible 7 y% # , 


DecorView 真 正 地 完成 了 添加 和 显示 这 两 个 过 程 ， 到 这 里 Activity 的 视 
图 才能 被 用 户 看 到 ， 如 下 所 示 。 


void makeVisible() { 
if (!mWindowAdded) { 
ViewManager wm = getWindowManager(); 
wm.addView(mDecor, getWindow( ) .getAttributes()); 
mWindowAdded = true; 
} 
mDecor .setVisibility(View.VISIBLE); 
} 


到 这 里 ，Activity 中 的 Window 的 创建 过 程 已 经 分 析 完 了 ， 读 者 对 
整个 过 程 是 不 是 有 了 更 进一步 的 理解 了 呢 ? 


8.3.2 Dialog 的 window 创 建 过 程 


Dialog 的 Window 的 创建 过 程 和 Activity 类 似 ， 有 如 下 几 个 步骤 。 
1. 创建 Window 


Dialog 中 Window 的 创建 同样 是 通过 PolicyManager 的 
makeNewWindow 方 法 来 完成 鸭 ， 从 8.3.1 和 中 可 以 知道 ， 创 建 后 的 对 象 
实际 上 束 是 PhoneWindow， 这 个 过 程 和 Activity 的 Window 的 创建 过 程 
是 一 致 的 ， 这 里 融 不 再 详细 说 明了 。 


Dialog(Context context, int theme, boolean 


createContextThemeWrapper) { 


mwWindowManager = 

(WindowManager )context.getSystemService(Context. 
WINDOW_SERVICE); 

Window w = PolicyManager .makeNewwindow(mContext); 

mwindow = w; 

w.setCallback(this); 

w.setOnWindowDismissedCallback(this); 

w.setWindowManager (mWindowManager, null, null); 

w.setGravity(Gravity.CENTER) ; 


mListenersHandler = new ListenersHandler(this); 


2. 初始 化 DecorView 并 将 Dialog 的 视图 添加 到 DecorView 中 


过 程 也 和 Activity 的 类 似 ， 都 是 通过 Window 去 添加 指定 的 布 
a o 


public void setContentView(int layoutResID) { 


mwWindow.setContentView(layoutResID); 


3. 将 DecorView 添 加 到 Window 中 并 显示 


在 Dialog 的 show 方 法 中 ， 过 WindowManager 将 DecorView 添 加 
下 Window 中 ， 如 下 所 示 。 


mwindowManager .addView(mDecor,1); 


mShowing = true; 


从 上 面 三 个 步骤 可 以 发 现 ，Dialog 的 Window 创 建 和 Activity 的 
Window 创 建 过 程 很 类 似 ， 二 者 几乎 没有 什么 区 别 。 当 Dialog 被 关闭 
时 ， 它 会 通过 WindowManager 来 %% BR DecorView 


mWindowManager.removeViewImmediate(mDecor) ° 


普通 的 Dialog 有 一 个 特殊 之 处 ， 那 就 是 必须 采用 Activity 的 
Context， 如 果 采 用 Application 的 Context， 那 么 束 会 报错 。 


Dialog dialog = new Dialog(this.getApplicationContext()); 
TextView textView = new TextView(this); 
textView.setText("this is toast!"); 
dialog.setContentView(textView) ; 


dialog.show(); 


上 述 代 码 运行 时 会 报错 ， 错 误 信 息 如 下 所 示 。 


E/AndroidRuntime(1185): Caused by: 
android. view.WindowManager$BadToken-Exception: Unable to add 
window --token null is not for an application 

E/AndroidRuntime( 1185): at 
android.view.ViewRootImpl.setView(ViewRoot-Impl.java:657) 

E/AndroidRuntime (1185): at 
android.view.WindowManagerImpl.addView(Window- 
ManagerImpl. java: 326) 

E/AndroidRuntime(1185): at 
android.view.WindowManagerImpl.addView(Window- 
ManagerImpl. java: 224) 

E/AndroidRuntime(1185) : at 


android.view.WindowManagerImp1$CompatMode - 
Wrapper .addView(WindowManagerImpl.java:149) 

E/AndroidRuntime(1185) : at 
android.app.Dialog.show(Dialog. java: 316) 

E/AndroidRuntime(1185) : at 
com.ryg.chapter_8.DemoActivity_1.initView(DemoActivity_1.java:2 
6) 

E/AndroidRuntime(1185) : at 
com.ryg.chapter_8.DemoActivity_1.onCreate(DemoActivity_1.java:1 
8) 

E/AndroidRuntime(1185) : at 
android.app.Activity.performCreate(Activity. java: 5086) 

E/AndroidRuntime(1185) : at 
android.app.Instrumentation.callActivityOn- 
Create(Instrumentation.java:1079) 

E/AndroidRuntime(1185): at 
android.app.ActivityThread.performLaunch- 


Activity(ActivityThread.java:2056) 


上 面 的 错误 信息 很 明确 ， 是 没有 应 用 token 所 导致 的 ， 而 应 用 token 
一 般 只 有 Activity 拥 有 ， 所 以 这 里 只 需要 用 Activity 作 为 Context 来 显示 
对 话 框 即 可 。 另 外 ， 系 统 Window 比 较 特 殊 ， 它 可 以 不 需要 token 
此 在 上 面 的 例子 中 ， 只 需要 指定 对 话 框 的 Window 为 系统 类 型 就 可 以 正 
党 弹出 对 话 框 。 在 本 章 一 开始 讲 到 ，WindowManager.LayoutParams 中 
的 type 表 示 Window 的 类 型 ， 而 系统 Window 的 层级 犯 围 是 2000~2999， 
这 些 层 级 范围 束 对 应 着 type 参 数 。 系 统 Window 的 层级 有 很 多 值 ， 对 于 


本 例 来 说 ， 可 以 选用 TYPE_SYSTEM_OVERLAY 来 指定 对 话 框 的 
Window 类 型 为 系统 Window， 如 下 所 示 。 


dialog.getWindow().setType(LayoutParams.TYPE_SYSTEM_ERROR) 


SR a Bll Y TE AndroidManifest 3 4 F E AA ADR M Ti BT LEH AR 
Window, 40 FATA > 


<uses-permission 


android: name="android.permission.SYSTEM_ALERT_WINDOW" /> 


8.3.3 ”Toast 的 Window 创 建 过 程 


Toast 和 Dialog 不 同 ， 它 的 工作 过 程 束 稍 显 复 杂 。 首 先 Toast 也 是 基 
nn 但 是 由 于 Toast 具 有 定时 a 这 一 功能 ， 所 以 系 

采用 了 Handler。 在 Toast 的 内 部 有 两 类 IPC 过 程 ， 第 一 类 是 Toast 访 问 
en ervice， 第 二 类 是 a 回调 
Toast 里 的 TN 接 口 。 关 于 IPC 的 一 些 知 识 ， 请 读者 参考 第 2 章 的 相关 内 
容 。 为 了 便于 摘 述 ， 下 面 将 NotificationManagerService 人 简称 为 NMS。 


Toast 属 于 系统 Window， 它 内 部 的 视图 由 两 种 方式 指定 ， 一 种 是 
系统 默认 的 样式 ， 另 一 种 是 通过 setView 方 法 来 指定 一 个 目 定义 View， 
不 管 如 何 ， 它 们 都 对 应 Toast 的 一 个 View 类 型 的 内 部 成 员 mNextView。 
Toast 提 供 了 show 和 cancel 分 别 用 于 显示 和 隐藏 Toast， 它 们 的 内 部 是 一 
个 IPC 过 程 ，show 方 法 和 cancel 方 法 的 实现 如 下 : 


public void show() { 


if (mNextView == null) { 


从 上 面 的 代码 可 以 看 到 ， 显 示 和 隐藏 Toast 都 需要 通过 NMS 来 实 
现 ， 由 于 NMS 运 行 在 系统 的 进程 中 ， 所 以 只 能 通过 远程 调用 的 方式 来 
显示 和 隐藏 Toast。 需 要 注意 的 是 TN 这 个 类 ， 它 是 一 个 Binder 类 ， 在 
Toast 和 和 NMS 进行 IPC 的 过 程 中 ， 当 NMS 人 处 理 Toast 的 显示 或 隐 闫 请求 时 


会 跨 进 程 回 调 TN 中 的 方法 ， 这 个 时 候 由 于 TN 运行 在 Binder 线 程 池 中 ， 
所 以 需要 通过 Handler 将 其 切换 到 当前 线程 中 。 这 里 的 当前 线程 是 指 发 
送 Toast 请 求 所 在 的 线程 。 注 意 ， 由 于 这 里 使 用 了 Handler， 所 以 这 意味 
着 Toast 无 法 在 没有 Looper 的 线程 中 弹出 ， 这 是 因为 Handler 需 要 使 用 
Looper 才 能 完成 切换 线程 的 功能 ， 关 于 Handler 和 Looper 的 具体 介绍 请 
参看 第 10 章 。 


首先 看 Toast 的 显示 过 程 ， 它 调用 了 NMS 中 的 enqueueToast 方 法 ， 
如 下 所 未 


INotificationManager service = getService(); 
String pkg = mContext.getOpPackageName(); 
TN tn = mTN; 
tn.mNextView = mNextView; 
try { 
service.enqueueToast(pkg, tn,mDuration); 
} catch (RemoteException e) { 
// Empty 
} 


NMS 的 enqueueToast 方 法 的 第 一 个 参数 表示 当前 应 用 的 包 名 ， 第 
二 个 参数 tm 表示 远程 回调 ， 第 三 个 参数 表示 Toast 的 时 长 。enqueueToast 
首先 将 Toast 请 求 封 闭 为 ToastRecord 对 象 并 将 其 添加 到 一 个 名 为 
mToastQueue 的 队列 中 。mToastQueue 其 实 是 一 个 ArrayList。 对 于 非 系 
统 应 用 来 说 ，mToastQueue 中 最 多 能 同时 存在 50 个 ToastRecord， 这 样 
做 是 为 了 防止 DOS (Denial of Service) 。 如 果 不 这 么 做 ， 试 想 一 下 ， 
如 果 我 们 通过 大 量 的 循环 去 连续 弹出 Toast， 这 将 会 导致 其 他 应 用 没有 
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正常 情况 下 ， 一 个 应 用 Pale 能 达到 上 限 ， 当 ToastRecord 被 添加 到 
mToastQueue 中 后 ，NMS 束 会 通过 showNextToastLocked 方 法 来 显示 当 
前 的 Toast。 下 面 的 代码 很 好 理解 ， 需 要 注意 的 是 ，Toast 的 显示 是 由 
ToastRecord 的 callback 来 完成 的 ， 这 个 callback 实 际 上 融 是 Toast 中 的 TN 
对 象 的 远程 Binder， 通 过 callback 来 访问 TN 中 的 方法 是 需要 跨 进 程 来 完 
成 的 ， 最 终 补 调用 的 TN 中 的 方法 会 运行 在 发 起 Toast 请 求 的 应 用 的 
Binder 线 程 池 中 。 


void showNextToastLocked() { 
ToastRecord record = mToastQueue.get(0); 
while (record != null) { 
if (DBG) Slog.d(TAG, "Show pkg=" + record.pkg + 
" callback=" + record.callback); 
try { 
record.callback.show(); 
scheduleTimeoutLocked(record); 
return; 
} catch (RemoteException e) { 
Slog.w(TAG,"Object died trying to show 
notification " + record.callback 
+ " in package " + 
record.pkg); 
// remove it from the list and let the 
process die 
int index = 
mToastQueue.index0f (record); 


if (index => 0) { 


Toast 显 示 以 后 ，NMS 还 会 通过 scheduleTimeoutLocked 方 法 来 发 送 
一 个 延 时 消息 ， 有 具体 的 延 时 取决 于 Toast 的 时 长 ， 如 下 所 示 。 


在 上 面 的 代码 中 ，LONG_DELAY 是 3.5s， 而 SHORT_DELAY 是 
2s ° WEIR AE DAY AY Va) Ja, NMS 4238 xf cancelToastLocked 77 IEA Ba yak 
Toast 并 将 其 从 mToastQueue 中 移 除 ， 这 个 时 候 如 果 mToastQueue 中 还 有 
其 他 Toast， 那 么 NMS 束 继续 显示 其 他 Toast 。 


Toast 的 隐藏 也 是 通过 ToastRecord 的 callback 来 完成 的 ， 这 同样 也 是 
一 次 IPC 过 程 ， 它 的 工作 方式 和 Toast 的 显示 过 程 是 类 似 的 ， 如 下 所 
示 o 


try { 
record.callback.hide(); 
} catch (RemoteException e) { 
Slog.w(TAG, "Object died trying to hide notification " + 
record.callback 
+ " in package " + record.pkg); 
// don't worry about this,we're about to remove it from 


// the list anyway 
t 


通过 上 面 的 分 析 ， 大 家 知道 Toast 的 显示 和 影响 过 程 实际 上 是 通过 
Toast 中 的 TN 这 个 类 来 实现 的 ， 它 有 两 个 方法 show 和 hide， 分 别 对 应 
Toast 的 显示 和 隐藏 。 由 于 这 两 个 方法 是 被 NMS 以 路 进程 的 方式 调用 
的 ， 因 此 它们 运行 在 Binder 线 程 池 中 。 为 了 将 执行 环境 切换 到 Toast 请 
求 所 在 的 线程 ， 在 它们 的 内 部 使 用 了 Handler， 如 下 所 示 。 


/** 
* schedule handleShow into the right thread 
7% 

@Override 

public void show() { 

if (localLOGV) Log.v(TAG, "SHOW: " + this); 


mHandler.post (mShow) ; 


上 述 代 码 中 ，mShow 和 mHide 是 两 个 Runnable， 它 们 内 部 分 别 调 
用 了 handleShow 和 handleHide 方法。 由 此 可 见 ，handleShow 和 
handleHide 才 是 真正 完成 显示 和 隐藏 Toast 的 地 方 。TN 的 handleShow 中 
会 将 Toast 的 视图 添加 到 Window 中 ， 如 下 所 示 。 


而 NT 的 handleHide 中 会 将 Toast 的 视图 从 Window 中 移 除 ， 如 下 所 
IR o 


到 这 里 Toast 的 Window 的 创建 过 程 已 经 分 析 完 了 ， 相 信 读 者 对 
Toast 的 工作 过 程 有 了 一 个 更 加 全 面 的 理解 了 。 除 了 上 面 已 经 提 到 的 
Activity、Dialog 和 Toast 以 外 ，PopupWindow、 采 单 以 及 状态 栏 等 都 是 
通过 Window 来 实现 的 ， 这 里 就 不 一 一 介绍 了 ， 读 者 可 以 找 目 己 感 兴趣 
的 内 容 来 分 析 。 


本 章 的 意义 在 于 让 读者 对 Window 有 一 个 更 加 清晰 的 认识 ， 同 时 能 
够 深刻 理解 Window 和 View 的 依赖 天 系 ， 这 有 助 于 理解 其 他 更 深层 次 的 
概念 ， 比 如 SurfaceFlinger。 通 过 本 章 读者 应 该 知道 ， 任 何 View 都 是 附 
属 在 一 个 window 上 面 的 ， 那 么 这 里 问 一 个 问题 : 一 个 应 用 中 到 的 有 多 
少 个 Window 呢 ? 相信 读者 都 已 经 清楚 了 。 


Bom ”四 大 组 件 的 工作 过 程 


本 章 讲述 Android 中 的 四 大 组 件 的 工作 过 程 。 说 到 四 大 组 件 ， 开 发 
者 都 再 熟悉 不 过 了 ， 它 们 是 Activity、Service、BroadcastReceiver 和 
ContentProvider。 如 何 使 用 四 大 组 件 ， 这 不 是 本 章 关 心 的 ， 毕 竟 这 是 
开发 者 都 味 悉 的 内 容 ， 本 章 按照 如 下 的 逻辑 来 分 机 Android 的 四 大 组 
件 : 首先 会 对 四 大 组 件 的 运行 状态 和 工作 方式 做 一 个 概括 化 的 描述 ， 
接着 对 四 大 组 件 的 工作 过 程 进行 分 析 ， 通 过 本 革 的 分 析 读 者 可 以 对 四 
大 组 件 有 一 个 更 深刻 的 认识 。 


本 章 主要 侧重 于 四 大 组 件 工作 过 程 的 分 析 ， 通 过 分 析 它 们 的 工作 
过 程 我 们 可 以 更 好 地 理解 系统 内 部 的 运行 机 制 。 本 章 的 意义 在 于 加 深 
读者 对 四 大 组 件 的 工作 方式 的 认识 ， 由 于 四 大 组 件 的 特殊 性 ， 我 们 有 
必要 对 它们 的 工作 过 程 有 一 定 的 了 解 ， 这 也 有 助 于 加 深 对 Android 整 体 
的 体系 结构 的 认识 。 很 多 情况 下 ， 只 有 对 Android 体 系 结构 有 一 定 认 
识 ， 在 实际 的 开发 中 才能 写 出 优秀 的 代码 。 


9.1 四 大 组 件 的 运行 状态 


Android 的 四 大 组 件 中 除了 BroadcastReceiver 以 外 ， 其 他 三 种 组 件 
都 必须 在 Android-Manifest 中 注册 ， 对 于 BroadcastReceiver 来 说 ， 它 既 
可 以 在 AndroidManifest 中 注册 也 可 以 通过 代码 来 注册 。 在 调用 方式 
E , Activity > Service 和 BroadcastReceiver 需要 借助 Intent ， 而 
ContentProvider 则 无 须 借助 Intent 。 


Activity 是 一 种 展示 型 组 件 ， 用 于 辐 用 户 直 接地 展示 一 个 界面 ， 并 
且 可 以 接收 用 户 的 输入 信息 从 而 进行 交互 。Activity 是 最 重要 的 一 种 组 
件 ， 对 用 户 来 说 ，Activity 束 是 一 个 Android 应 用 的 全 部 ， 这 是 因为 其 
他 三 大 组 件 对 用 户 来 说 都 是 不 可 感知 的 。 Activity 的 局 动 由 Intent 触 
发 ， 其 中 Intent 可 以 分 为 显 式 Intent 和 隐 式 Intent， 显 式 Intent 可 以 明确 地 
指 癌 一 个 Activity 组 件 ， 隐 式 Intent 则 指 癌 一 个 或 多 个 目标 Activity 组 
件 ， 当 然 也 可 能 没有 任何 一 个 Activity 组 件 可 以 处 理 这 个 隐 式 Intent 。 
一 个 Activity 组 件 可 以 具有 特定 的 局 动 模式 。 关 于 Activity 的 启动 模式 
在 第 1 章 中 已 经 做 了 介绍 ， 同 一 个 Activity 组 件 在 不 同 的 启动 模式 下 会 
有 不 同 的 效果 。Activity 组 件 是 可 以 停止 的 ， 在 实际 开发 中 可 以 通过 
Activity 的 finish 方 法 来 结束 一 个 Activity 组 件 的 运行 。 由 此 来 看 ， 
Activity 组 件 的 主要 作用 是 展示 一 个 界面 并 和 用 户 交 互 ， 它 扮演 的 是 一 
种 前 台 界 面 的 角色 。 


Service 是 一 种 计算 型 组 件 ， 用 于 在 后 台 执 行 一 系列 计算 任务 。 由 
于 Service 组 件 工作 在 后 台 ， 因 此 用 户 无 法 直接 感知 到 它 的 存在 。 
Service 组 件 和 Activity 组 件 略 有 不 同 ，Activity 组 件 只 有 一 种 运行 模 
式 ， 即 Activity 处 于 启动 状态 ， 但 是 Service 组 件 却 有 两 种 状态 : 启动 状 
态 和 绑 定 状态 。 当 Service 组 件 处 于 启动 状态 时 ， 这 个 时 候 Service 内 部 
可 以 做 一 些 后 台 计 算 ， 并 且 不 需要 和 外 界 有 直接 的 交互 。 尽 管 Service 
组 件 是 用 于 执行 后 台 计 算 的 ， 但 是 它 本 吴 是 运行 在 主线 程 中 的 ， 因 此 
耗 时 的 后 台 计 算 仍 然 需要 在 单独 的 线程 中 去 完成 。 当 Service 组 件 处 于 
绑 定 状态 时 ， 这 个 时 候 Service 内 部 同样 可 以 进行 后 台 计 算 ， 但 是 处 于 
这 种 状态 时 外 界 可 以 很 方便 地 和 Service 组 件 进行 通信 。Service 组 件 也 
是 可 以 停止 的 ， 人 停止 一 个 Service 组 件 稍 显 复杂 ， 需 要 灵活 采用 
stopService 和 unBindService 这 两 个 方法 才能 完全 停止 一 个 Service 组 


te? 


BroadcastReceiver 是 一 种 消息 型 组 件 ， 用 于 在 不 同 的 组 件 乃 至 不 
同 的 应 用 之 间 传 递 消 息 。BroadcastReceiver 同 样 无 法 被 用 户 直 接 感 
知 ， 因 为 它 工 作 在 系统 内 部 。BroadcastReceiver 也 叫 广播 ， 广 播 的 注 
册 有 两 种 方式 : 静态 注册 和 动态 注册 。 静 态 注 册 是 指 在 
AndroidManifest 中 注册 广播 ， 这 种 广播 在 应 用 安装 时 会 被 系统 解析 ， 
此 种 形式 的 广播 不 需要 应 用 局 动 束 可 以 收 到 相应 的 广播 。 动 态 注册 广 
播 需 要 通过 Context.registerReceiver0 来 实现 ， 并 且 在 不 需要 的 时 候 要 
通过 Context.unRegisterReceiver0 来 解除 广播 ， 此 种 形态 的 广播 必须 要 
应 用 局 动 才能 注册 并 接收 广播 ， 因 为 应 用 不 局 动 融 无 法 注册 广播 ， 无 
法 注册 广播 就 无 法 收 到 相应 的 广播 。 在 实际 开发 中 通过 Context 的 一 系 
列 send 方 法 来 发 送 广播 ， 被 发 送 的 广播 会 被 系统 发 送 给 感 兴趣 的 广播 
接收 者 ， 发 送 和 接收 过 程 的 匹配 是 通过 广播 接收 者 的 <intent-filter> 来 
描述 的 。 可 以 发 现 ，BroadcastReceiver 组 件 可 以 用 来 实现 低 耦 合 的 观 
察 者 模式 ， 观 察 者 和 被 观察 者 之 间 可 以 没有 任何 耦合 。 由 于 
BroadcastReceiver 的 特性 ， 它 不 适合 用 来 执行 耗 时 操作 。 
BroadcastReceiver 组 件 一 般 来 说 不 需要 停止 ， 它 也 没有 停止 的 概念 。 


ContentProvider 是 一 种 数据 共享 型 组 件 ， 用 于 问 其 他 组 件 乃 至 其 
他 应 用 共享 数据 。 和 了 BroadcastReceiver 一 样 ，ContentProvider 同 样 无 法 
被 用 户 直 接 感知 。 对 于 一 个 ContentProvider 组 件 来 说 ， 它 的 内 部 需要 
实现 增删 改 查 这 四 种 操作 ， 在 它 的 内 部 维持 着 一 份 数据 集合 ， 这 个 数 
据 集合 既 可 以 通过 数据 库 来 实现 ， 也 可 以 采用 其 他 任何 类 型 来 实现 ， 
比如 List 和 Map ，ContentProvider 对 数据 集合 的 具体 实现 并 没有 任何 要 
求 。 需 要 注意 的 是 ，ContentProvider 内 部 的 insert、delete、update 和 
query 方 法 需要 处 理 好 线程 同步 ， 因 为 这 几 个 方法 是 在 Binder 线 程 池 中 
被 调用 的 ， 另 外 ContentProvider 组 件 也 不 需要 手动 停止 。 


9.2 ”Activity 的 工作 过 程 


本 市 讲述 的 内 容 古 Activity 的 工作 过 程 。 为 了 方便 日 肖 的 开发 工 
作 ， 系 统 对 四 大 组 件 的 工作 过 程 进行 了 很 大 程度 的 封 锋 ， 这 使 得 开发 
者 无 须 天 注 实 现 细节 即 可 快速 地 使 用 四 大 组 件 。Activity 作 为 很 重要 的 
一 个 组 件 ， 其 内 部 工作 过 程 系统 当然 也 是 做 了 很 多 的 封装 ， 这 种 封 狼 
使 得 局 动 一 个 Activity 变 得 异常 侧 单 。 在 显 式 调用 的 情形 下 ， 只 需要 通 
过 如 下 代码 即 可 完成 : 


Intent intent = new Intent(this, TestActivity.class); 


startActivity(intent); 


通过 上 面 的 代码 即 可 局 动 一 个 具体 的 Activity， 然 后 新 Activity 残 
会 被 系统 局 动 并 展示 在 用 户 的 眼前 。 这 个 过 程 对 于 Android 开 发 者 来 说 
最 普通 不 过 了 ， 这 也 是 很 理 所 应 当 的 事 ， 但 是 有 没有 想 过 系统 内 部 到 
底 是 如 何 启动 一 个 Activity 的 呢 ? 比如 新 Activity 的 对 象 是 在 何 时 创建 
的 ? Activity 的 onCreate 方 法 又 是 在 何 时 被 系统 回调 的 呢 ? 读者 可 能 会 
有 疑问 : 在 日 党 开发 中 并 不 需要 了 解 Activity 底 层 到 底 是 怎么 工作 的 ， 
那么 了 解 它 们 又 有 什么 意义 呢 ? 没 错 ， 在 日 常 开发 中 是 不 需要 了 解 系 
统 的 底层 工作 原理 ,但 是 如 有 果 想 要 在 技术 上 有 进一步 的 提高 ， 那 么 就 
必须 了 解 一 些 系统 的 工作 原理 ， 这 是 一 个 开发 人 员 日 后 成 长 为 高 级 工 
程 师 乃 至 架构 师 所 必须 具备 的 技术 能 力 。 从 另外 一 个 角度 来 说 ， 
Android 作 为 一 个 优秀 的 基于 Linux 的 移动 操作 系统 ， 其 内 部 一 定 有 很 
多 值得 我 们 学 习 和 借鉴 的 地 方 ， 因 此 了 解 系统 的 工作 过 程 区 是 学 习 
Android 操 作 系统 。 通 过 对 Android 操 作 系 统 的 学 习 可 以 提高 我 们 对 操 
作 系 统 在 技术 实现 上 的 理解 ， 这 对 于 加 强 开 发 人 员 的 内 功 是 很 有 帮助 
的 。 但 是 有 一 点 ， 由 于 Android 的 内 部 实现 多 数 都 比较 复杂 ， 在 人 研究 内 


部 实现 上 应 该 更 加 侧重 于 对 整体 流程 的 把 握 ， 而 不 能 深入 代码 细 市 不 
能 目 拔 ， 太 深入 代码 细 克 往往 会 导致 "只 见 树木 不 见 和 森林 ”的 状态 。 处 
于 这 种 状态 下 ， 无 法 对 整体 流程 建立 足够 的 认识 ， 取 而 代 之 的 是 烦 瑞 
的 代码 细 市 ， 但 是 代码 细 市 本 映 并 不 具有 太 多 的 指导 意义 ， 因 此 这 种 
学 习 状 态 是 要 极力 避免 的 。 鉴 于 这 一 点 ， 本 草 对 Activity 以 及 其 他 三 个 
组 件 的 工作 过 程 的 分 析 将 会 侧重 于 整体 流程 的 讲解 ， 目 的 是 为 了 让 读 
者 对 四 大 组 件 的 工作 过 程 有 一 个 感性 的 认识 并 能 够 给 予 上 层 开发 一 些 
站 导 意 义 。 但 凡事 不 古 绝对 的 ， 如 末 开 发 者 从 事 的 工作 是 Android Rom 
开发 ， 那 的 层 代 码 细 市 还 古 要 有 所 涉猎 的 。 


本 节 主 要 分 析 Activity 的 启动 过 程 ， 通 过 本 节 读 者 可 以 对 Activity 
的 启动 过 程 有 一 个 感性 的 认识 ， 至 于 启动 模式 以 及 任务 栈 等 概念 本 和 
中 并 未 涉及 ， 读 者 感 兴趣 的 话 可 以 查看 相应 的 代码 细节 即 可 。 


我 们 从 Activity 的 startActivity 方 法 开始 分 析 ，startActivity 方 法 有 好 
几 种 重 载 方式 ， 但 它们 最 终 都 会 调用 startActivityForResult 方 法 ， 它 的 
实现 如 下 所 示 。 


public void startActivityForResult(Intent intent,int 
requestCode, 
@Nullable Bundle options) { 
if (mParent == null) { 
Instrumentation.ActivityResult ar = 


mInstrumentation.execStartActivity( 


this, mMainThread.getApplicationThread( ),mToken, this, 
intent, requestCode, options); 


if (ar != null) { 


在 上 面 的 代码 中 ， 我 们 只 需要 关注 mParent == null 这 部 分 逻辑 即 
可 。mParent 代 表 的 是 ActivityGroup ，ActivityGroup 最 开始 被 用 来 在 一 
TAEFERASTF Activity, HEHFEAP 13 中 已 经 被 废弃 了 ， 系 统 
推荐 采用 Fragment 来 代替 ActivityGroup，Fragment 的 好 处 就 不 用 多 说 
了 。 在 上 面 的 代码 中 需要 注意 mMainThread.getApplicationThreadO 〇 这 个 


参数 ， 它 的 类 型 是 ApplicationThread , ApplicationThread 是 
ActivityThread 的 一 个 内 部 类 ， 通 过 后 面 的 分 析 可 以 发 现 ， 
ApplicationThread 和 ActivityThread 在 Activity 的 启动 过 程 中 发 挥 着 很 重 


要 的 作用 。 接 着 看 一 下 Instrumentation 的 execStartActivity 方 法 ， 如 下 所 
Be 


从 上 面 的 代码 可 以 看 出 ， 局 动 Activity 真 正 的 实现 由 
ActivityManagerNative.getDefault() 的 startActivity 方法 来 完成 。 
ActivityManagerService (下 面 简称 为 AMS ) 继承 HB 
ActivityManagerNative, ， 而 ActivityManagerNative 继 承 目 Binder 并 实现 
了 IActivityManager 这 个 Binder 接 口 ， 因 此 AMS 也 是 一 个 Binder， 它 是 
IActivityManager 的 具体 实现 。 由 于 ActivityManagerNative.getDefault() 


其 实 是 一 个 IActivityManager 类 型 的 Binder 对 象 ， 因 此 它 的 具体 实现 是 
AMS。 可 以 发 现 ， 在 ActivityManagerNative 中 ，AMS 这 个 Binder 对 象 
采用 单 例 模式 对 外 提供 ，Singleton 是 一 个 单 例 的 封装 类 ， 第 一 次 调用 
它 的 get 方 法 时 它 会 通过 create 方 法 来 初始 化 AMS 这 个 Binder 对 象 ， 在 后 
续 的 调用 中 则 直接 返回 之 前 创建 的 对 象 ， 这 个 过 程 的 源码 如 下 所 示 。 


从 上 面 的 分 BD 以 知道 ， Activity 由 
ActivityManagerNative.getDefault() 来 局 By 而 
ActivityManagerNative.getDefault0 实 际 上 是 AMS ， 因 此 Activity 的 启动 
过 程 又 转移 到 了 AMS 中 ， 为 了 继续 分 析 这 个 过 程 ， 只 需要 得 看 AMS 的 
startActivity 方 法 即 可 。 在 分 析 AMS 的 的 startActivity 方 法 之 前 ， 我 们 先 
回 过 头 来 看 一 下 Instrumentation 的 execStartActivity 方 法 ， 其 中 有 一 行 代 
13: checkStartActivityResult(result,intent)， 直 观 上 看 起 来 这 个 方法 的 作 
用 像 是 在 检查 启动 Activity 的 结果 ， 它 的 具体 实现 如 下 所 示 。 


/** @hide */ 
public static void checkStartActivityResult(int res,Object 
intent) { 
if (res => ActivityManager.START_SUCCESS) { 
return; 
J 
switch (res) { 
case ActivityManager .START_INTENT_NOT_RESOLVED: 
case ActivityManager .START_CLASS_NOT_FOUND: 
if (intent instanceof Intent && 
((Intent)intent).getComponent() != null) 
throw new 
ActivityNotFoundException( 
"Unable to find 


explicit activity class " 


((Intent)intent).getComponent().toShortString() 


从 上 面 的 代码 可 以 看 出 ，checkStartActivityResult 的 作用 很 明显 ， 
就 是 检查 局 动 Activity 的 结果 。 当 无 法 正确 地 局 动 一 个 Activity 时 ， 这 
个 方法 会 抛 出 异常 信息 ， 其 中 最 误 悉 不 过 的 瓯 是 “Unable to find explicit 
activity class; have you declared this activity in your 
AndroidManifest.xml?” X ^ F% T, 4 JR Activity X HA Æ 
AndroidManifest 中 注册 时 ， 就 会 抛 出 这 个 异常 。 


接着 我 们 继续 分 析 AMS 的 startActivity 方 法 ， 如 下 所 示 。 


public final int startActivity(IApplicationThread 
caller, String callingPackage, 
Intent intent,String resolvedType, IBinder 
resultTo, String resultwho, int requestCode, 
int startFlags,ProfilerInfo profilerInfo, Bundle 
options) { 
return 
startActivityAsUser(caller, callingPackage, intent, resolved- 


Type, resultTo, 


resultwho, requestCode, startFlags, profilerInfo, options, 


UserHandle.getCallingUserId()); 


public final int startActivityAsUser (IApplicationThread 
caller,String callingPackage, 


Intent intent,String resolvedType, IBinder 


resultTo, String resultwho, int requestCode, 
int startFlags,ProfilerInfo profilerInfo, Bundle 
options,int userId) { 
enforceNotIsolatedCaller("startActivity"); 
userId = 
handleIncomingUser (Binder .getCallingPid(),Binder.getCalling- 
Uid(), userId, 


false, ALLOW_FULL_ONLY, "startActivity",null); 
// TODO: Switch to user app stacks here. 
return 
mStackSupervisor.startActivityMayWait (caller, -1,calling 


Package, intent, 


resolvedType, null, null, resultTo, resultwho, requestCode, startFlag 


S, 


profilerInfo, null, null, options, userId, null, null); 


} 


可 以 看 出 ，Activity 的 启动 过 程 又 转移 到 了 ActivityStackSupervisor 
的 startActivity-MayWait 方 法 中 了 ， 在 startActivityMayWait 中 又 调用 了 
startActivityLocked 方法 ， 然 后 startActivityLocked 方法 又 调用 了 
startActivityUncheckedLocked 方 法 ， 接 着 startActivityUncheckedLocked 
又 调用 了 ActivityStack 的 resumeTopActivitiesLocked 方 法 ， 这 个 时 候 启 
动 过 程 已 经 从 ActivityStackSupervisor 转 移 到 了 ActivityStack。 


ActivityStack 的 resumeTopActivitiesLocked 方 法 的 实现 如 下 所 示 。 


从 上 面 的 代码 可 以 看 出 ，resumeTopActivityLocked 调用 了 
resumeTopActivityInnerLocked 77 法 ，resumeTopActivityInnerLocked 方 
法 又 调用 了 ActivityStackSupervisor 的 startSpecificActivityLocked 方 法 ， 
startSpecificActivityLocked 的 源码 如 下 所 示 。 


从 上 面 代 和 码 可 以 看 出 startSpecificActivityLocked 77 14 Val H T 
realStartActivityLocked 方 法 。 为 了 更 清晰 地 说 明 Activity 的 局 动 过程 在 
ActivityStackSupervisor 和 ActivityStack 之 间 的 传递 顺序 ， 这 里 给 出 了 一 
张 流程 图 ， 如 图 9-1 所 示 。 


startActivityMay Wait 


startActivityLocked 


startActivityUncheckedLocked 


resumeTopActivitiesLocked 


startSpecificActivityLocked . resumeTopActivityInnerLocked | 


ActivityStack 


realStartActivityLocked | 


ActivityStackSupervisor 
图 9-1 Activity 的 启动 过 程 在 ActivityStackSupervisor 和 ActivityStack 之 间 的 传递 顺序 


在 ActivityStackSupervisor 的 realStartActivityLocked 方 法 中 有 如 下 一 
段 代码 : 


), 
profilerInfo); 


上 面 的 这 段 代 码 很 重要 ， 其 中 appthread 的 类 型 为 
IApplicationThread, IApplicationThreadH) = HA 4N F : 


public interface IApplicationThread extends IInterface { 
void schedulePauseActivity(IBinder token, boolean 
finished, boolean userLeaving, 
int configChanges, boolean dontReport) throws 
RemoteException; 
void scheduleStopActivity(IBinder token,boolean showWindow, 
int configChanges) throws RemoteException; 
void scheduleWindowVisibility(IBinder token, boolean 
showwindow) throws 
RemoteException; 
void scheduleSleeping(IBinder token,boolean sleeping) 
throws RemoteException; 
void scheduleResumeActivity(IBinder token, int 
procState, boolean 
isForward, Bundle resumeArgs) 
throws RemoteException; 
void scheduleSendResult(IBinder token, List<ResultInfo> 
results) throws 
RemoteException; 
void scheduleLaunchActivity(Intent intent, IBinder 


token,int ident, 


ActivityInfo info, Configuration 
curConfig, CompatibilityInfo 
compatInfo, 
IVoiceInteractor voicelnteractor,int 
procState, Bundle state, 
PersistableBundle 
persistentState, List<ResultInfo> pendingResults, 
List<Intent> pendingNewIntents, boolean 
notResumed, boolean 
isForward, 
ProfilerInfo profilerInfo) throws 
RemoteException; 
void scheduleRelaunchActivity(IBinder 
token, List<ResultInfo> pending- 
Results, 
List<Intent> pendingNewIntents, int 
configChanges, 
boolean notResumed, Configuration config) 
throws RemoteException; 
void scheduleNewIntent(List<Intent> intent, IBinder 
token) throws 
RemoteException; 
void scheduleDestroyActivity(IBinder token, boolean 
finished, 
int configChanges) throws RemoteException; 
void scheduleReceiver(Intent intent,ActivityInfo 


info,Compatibility- 


Info compatinfo, 
int resultCode, String data, Bundle 
extras,boolean sync, 
int sendingUser,int processState) throws 
RemoteException; 
static final int BACKUP_MODE_INCREMENTAL = 0; 
static final int BACKUP_MODE_FULL = 1; 
static final int BACKUP_MODE_RESTORE = 2; 
static final int BACKUP_MODE_RESTORE_FULL = 3; 
void scheduleCreateBackupAgent (ApplicationInfo 
app, CompatibilityInfo 
compatInfo, 
int backupMode) throws RemoteException; 
void scheduleDestroyBackupAgent (ApplicationInfo 
app, CompatibilityInfo 
compatInfo) 
throws RemoteException; 


void scheduleCreateService(IBinder token,ServiceInfo 


info, 
CompatibilityInfo compatInfo,int processState) 
throws 
RemoteException; 
void scheduleBindService(IBinder token, 
Intent intent,boolean rebind,int processState) 
throws 


RemoteException; 


void scheduleUnbindService(IBinder token, 


Intent intent) throws RemoteException; 
void scheduleServiceArgs(IBinder token, boolean 
taskRemoved, int 
startld, 
int flags, Intent args) throws RemoteException; 
void scheduleStopService(IBinder token) throws 


RemoteException; 


因为 它 继承 了 Imterface 接 口 ， 所 以 它 是 一 个 Binder 类 型 的 接口 。 
从 IApplicationThread 声 明 的 接口 方法 可 以 看 出 ， 其 内 部 包含 了 大 量 启 
动 、 停 止 Activity 的 接口 ， 此 外 还 包含 了 局 动 和 停止 服务 的 接口 。 从 接 
口 方法 的 命名 可 以 猜测 ，IApplicationThread 这 个 Binder 接 口 的 实现 者 
完成 了 大 量 和 Activity 以 及 Service 启 动 /停止 相关 的 功能 ， 事 实证 明 的 
确 是 这 样 的 。 


AB A TApplicationThread HY) E M Æ FI EE tr AWE? BRM 
ActivityThread F 的 内 部 类 ApplicationThread ， 下 面 来 看 一 下 
ApplicationThread 的 定义 ， 如 下 所 示 。 


private class ApplicationThread extends 
ApplicationThreadNative 
public abstract class ApplicationThreadNative extends 
Binder 


implements IApplicationThread 


可 以 看 出 ，ApplicationThread 继 承 了 ApplicationThreadNative ， 而 
ApplicationThreadNative 则 继承 了 Binder 并 实现 了 IApplicationThread 接 
口 。 如 果 读 者 还 记得 系统 为 AIDL 文 件 自动 生成 的 代码 ， 就 会 发 现 
A 的 作用 其 实 和 系统 为 AIDL 文 件 生成 的 类 是 一 
样 的 ， 这 方面 的 知识 在 第 2 章 已 经 做 了 介绍 ， 读 者 可 以 查看 第 2 草 的 相 


ak 
ot 
de 


TE ApplicationThreadNative AY 内 部 ， 还 有 一 个 
ApplicationThreadProxy 类 ， 这 个 类 的 实现 如 下 所 示 。 相 信 读 者 有 一 种 
似曾相识 的 感觉 ， 其 实 这 个 内 部 类 也 是 系统 为 AIDL 文 件 目 动 生 成 的 代 
理 类 。 种 种 迹象 表明 ，ApplicationThreadNative 就 是 IApplicationThread 
的 实现 者 ， 由 于 ApplicationThreadNative 被 系统 定义 为 抽象 类 ， 所 以 
ApplicationThread 就 成 了 IApplicationThread 最 终 的 实现 者 。 


class ApplicationThreadProxy implements IApplicationThread 


private final IBinder mRemote; 

public ApplicationThreadProxy(IBinder remote) { 
mRemote = remote; 

} 

public final IBinder asBinder() { 


return mRemote; 


public final void schedulePauseActivity(IBinder 
token, boolean finished, 
boolean userLeaving, int configChanges, boolean 


dontReport ) 


throws RemoteException { 


Parcel data = Parcel.obtain(); 


data.writeInterfaceToken(IApplicationThread.descriptor); 
data.writeStrongBinder(token); 
data.writeInt(finished ? 1 : 0); 
data.writeInt(userLeaving ? 1 :0); 
data.writeInt(configChanges ) ; 


data.writeInt(dontReport ? 1 : 0); 


mRemote. transact (SCHEDULE_PAUSE_ACTIVITY_TRANSACTION, data, null, 
IBinder .FLAG_ONEWAY) ; 


data.recycle(); 


public final void scheduleStopActivity(IBinder 
token, boolean showWindow, 
int configChanges) throws RemoteException { 


Parcel data = Parcel.obtain(); 


data.writeInterfaceToken(IApplicationThread.descriptor); 
data.writeStrongBinder(token); 
data.writeInt(showwWindow ? 1 : 0); 


data.writeInt(configChanges); 


mRemote.transact (SCHEDULE_STOP_ACTIVITY_TRANSACTION, data, null, 
IBinder.FLAG_ONEWAY) ; 


data.recycle(); 


绕 了 一 大 圈 ，Activity 的 启动 过 程 最 终 回 到 了 ApplicationThread 
中 ， ApplicationThread 通 过 scheduleLaunchActivity 方法 来 局 动 
Activity， 代 码 如 下 所 示 。 


ZE ApplicationThreadF, scheduleLaunchActivityH) LX DARA, 
是 发 送 一 个 局 动 Activity 的 消息 交 由 Handler 处 理 ， 这 个 Handler 有 着 一 
个 很 简 活 的 名 字 : H。sendMessage 的 作用 是 发 送 一 个 消息 给 了 HH 处 理 ， 
它 的 实现 如 下 所 示 。 


接着 来 看 一 下 Handler H 对 消息 的 处 理 ， 如 下 所 示 。 


M Handler H 对 “LAUNCH_ACTIVITY” 这 个 消息 的 处 理 可 以 知道 ， 
Activity 的 启动 过 程 由 ActivityThread 的 handleLaunchActivity 方 法 来 实 
现 ， 它 的 源码 如 下 所 示 。 


从 上 面 的 源码 可 以 看 出 ，performLaunchActivity 方 法 最 终 完 成 了 
Activity 对 象 的 创建 和 启动 过 程 ， Ff  ActivityThread 通过 
handleResumeActivity 方 法 来 调用 被 启动 Activity 的 onResume 这 一 生命 
周期 方法 。 


performLaunchActivity 这 个 方法 主要 完成 了 如 下 几 件 事 。 
1. 从 ActivityClientRecord 中 获取 待 启 动 的 Activity 的 组 件 信 息 


2. 通过 Instrumentation 的 newActivity 方 法 使 用 类 加 载 器 创建 
Activity 对 象 


u 


至 于 Instrumentation 的 newActivity， 它 的 实现 比较 简单 ， 就 是 通过 
类 加 载 器 来 创建 Activity 对 象 : 


3. 通过 LoadedApk 的 makeApplication 方 法 来 尝试 创建 Application 
对 象 


从 makeApplication 的 实现 可 以 看 如 果 Application 已 经 被 创建 
过 了 ， 那 么 就 不 会 再 重复 创建 了 ， 意味 着 一 个 应 用 只 有 一 个 
Application 对 象 。Application 对 和 象 的 创 Le 也 是 通过 Instrumentation 来 完 
成 的 ， 这 个 过 程 和 Activity 对 象 的 创建 一 样 ， 都 是 通过 类 加 载 器 来 实现 
的 。 Application 创建 完毕 后 ， 系 统 会 通过 Instrumentation 的 
callApplicationOnCreate 来 调用 Application 的 onCreate 方 法 。 


4. 创建 ContextImpl 对 象 并 通过 Activity 的 attach 方 法 来 完成 一 些 重 
要 数据 的 初始 化 


Context appContext = 
createBaseContextForActivity(r,activity); 
CharSequence title = 
r.activityInfo.loadLabel(appContext.getPackage- 
Manager ()); 
Configuration config = new 
Configuration(mCompatConfiguration); 
if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity " 
+ r.activityInfo.name + " with config " + 


config); 
activity.attach(appContext, this, getInstrumentation(),r.token, 
r.ident,app,r.intent,r.activityInfo, title,r.parent, 


r.embeddedID, r.lastNonConfigurationInstances, config, 


r.voicelnteractor); 


ContextImpl 是 一 个 很 重要 的 数据 结构 ， 它 是 Context 的 具体 实现 ， 
Context 中 的 大 部 分 逻辑 都 是 由 ContextImpl 来 完成 的 。ContextImpl 是 通 
过 Activity 的 attach 方 法 来 和 Activity 建 立 天 联 的 ， 除 此 以 外 ， 在 attach 方 
法 中 Activity 还 会 完成 Window 的 创建 并 建立 自己 和 Window 的 关联 ， 这 
样 当 Window 接 收 到 外 部 输入 事件 后 瓯 可 以 将 事件 传递 给 Activity。 


5. 调用 Activity 的 onCreate 方 法 


E ais DAR r.state), FH T Activity 
的 onCreate 已 经 被 调用 ， 这 也 意味 着 Activity 已 经 完成 了 整个 启动 过 
程 。 


9.3 ”Service 的 工作 过 程 


在 9.2 广 中 介绍 了 Activity 的 工作 过 程 ， 本 市 将 介绍 Service 的 工作 过 
程 ， 通 过 本 厄 的 分 析 ， 读 者 将 会 对 Service 的 一 些 工 作 原理 有 更 进一步 
的 认识 ， 比 如 Service 的 局 动 过 程 和 绑 定 过 程 。 在 分 析 Service 的 工作 过 
程 之 前 ， 先 看 一 下 如 何 使 用 一 个 Service。Service 分 为 两 种 工作 状态 ， 
一 种 是 启动 状态 ， 主 要 用 于 执行 后 台 计 算 ; 另 一 种 是 绑 定 状态 ， 主 要 
用 于 其 他 组 件 和 Service 的 交互 。 需 要 注意 的 是 ，Service 的 这 两 种 状态 
是 可 以 共存 的 ， 即 Service 既 可 以 处 于 局 动 状态 也 可 以 同时 处 于 绑 定 状 
态 。 通 过 Context 的 startService 方 法 即 可 启动 一 个 Service， 如 下 所 示 。 


Intent intentService = new Intent(this,MyService.class); 


startService(intentService); 


通过 Context HY bindService 7 ZEIT UFENTAHN— NT 
Service, AI BAAR ° 


Intent intentService = new Intent(this,MyService.class); 


bindService(intentService, mServiceConnection, BIND_AUTO_CREATE) ; 


9.3.1 ”Service 的 启动 过 程 


Service 的 启动 过 程 从 ContextWrapper 的 startActivity 开 始 ， 如 下 所 
IR ° 


public ComponentName startService(Intent service) { 


return mBase.startService(service); 


上 面 代 码 的 mBase 的 类 型 是 ContextImp1， 在 9.2 世 中 我 们 知道 ， 
Aa 建 时 会 通过 attach 方 法 将 一 个 ContextImpl 对 象 天 联 起 来 ， 
文 个 ContextImpl 对 象 就 是 上 述 代 码 中 的 mBase。 从 ContextWrapper 的 实 
现 可 以 看 出 ， 其 大 部 分 操作 都 是 通过 mBase 来 实现 的 ， 在 设计 模式 中 
这 是 一 种 典型 的 桥接 模式 。 下 面 继续 看 ContextImpl 的 startActivity 的 实 
现 ， 如 下 所 示 。 


public ComponentName startService(Intent service) { 
warnIfCallingFromSystemProcess(); 


return startServiceCommon(service,mUser); 


} 
return cn; 
} catch (RemoteException e) { 


return null; 


在 ContextImpl ¥ , startService 7 14 & Val FA startServiceCommon 77 
We 而 startService-Common >) 法 X 会 Jk 过 
ActivityManagerNative.getDefault() 这 个 对 象 来 启动 一 个 服务 。 对 于 
ActivityManagerNative.getDefault() 这 个 对 象 ， 我 们 应 该 有 点 印象 ， 在 
92 Y Pw fT T HAN oe, EX bi ms AMS 
(ActivityManagerService) ， 这 里 就 不 再 重复 说 明了 。 需 要 注意 的 
是 ， 在 上 壕 代 码 中 通过 AMS 来 启动 服 务 的 行为 是 一 个 远程 过 程 调用 。 
AMS 的 startService 方 法 的 实现 如 下 所 示 。 


public ComponentName startService(IApplicationThread 
caller,Intent service, 
String resolvedType, int userId) { 
enforceNotIsolatedCaller("startService"); 
// Refuse possible leaked file descriptors 
if (service != null && service.hasFileDescriptors() == 
true) { 
throw new IllegalArgumentException("File 
descriptors passed in Intent"); 


} 
if (DEBUG_SERVICE) 


Slog.v(TAG, "startService: " + service + " 
type=" + resolvedType); 
synchronized(this) { 
final int callingPid = Binder.getCallingPid(); 
final int callingUid = Binder.getCallingUid(); 
final long origId = 
Binder .clearCallingldentity(); 
ComponentName res = 


mServices.startServiceLocked(caller,service, 


resolvedType, callingPid, callingUid, userId); 
Binder .restoreCallingIdentity(origId); 


return res; 


在 上 面 的 代码 中 ，AMS 会 通过 mServices 这 个 对 象 来 完成 Service 后 
续 的 启动 过 程 ，mServices 对 象 的 类 型 是 ActiveServices，ActiveServices 
是 一 个 辅助 AMS 进 行 Service 管 理 的 类 ， 包 括 Service 的 启动 、 绑 定 和 停 
ik 等 。 在 ActiveServices 的 startServiceLocked 方法 的 尾部 会 调用 
startServicelnnerLocked 方法 startServicelnnerLocked 的 实现 如 下 所 
Ro 


ComponentName startServiceInnerLocked(ServiceMap 
smap, Intent service, 
ServiceRecord r,boolean callerFg,boolean 


addToStarting) { 


在 上 述 代 码 中 ，ServiceRecord 描 述 的 是 一 个 Service 记录， 
ServiceRecord — E ii F A E 4 Service 的 启动 过 程 。 
startServiceInnerLocked 方 法 并 没有 完成 具体 的 启动 工作， 而 是 把 后 续 
的 工作 交 给 了 bringUpServiceLocked 方法 来 处 理 ， 在 
bringUpServiceLocked 方 法 中 又 调用 了 realStartServiceLocked 方 法 。 从 
名 字 上 来 看 ， 这 个 方法 应 该 是 真正 地 启动 一 个 Service， 它 的 实现 如 下 
所 示 。 


在 realStartServiceLocked 方法 中 ， 首 先 通 过 app.thread 的 
scheduleCreateService 方 法 来 创建 Service 对 象 并 调用 其 onCreate， 接 着 
再 通过 sendServiceArgsLocked 方 法 来 调用 Service 的 其 他 方法 ， 比 如 
onStartCommand ， 这 两 个 过 程 均 是 进程 间 通 信 。app.thread 对 象 是 
IApplicationThread 类 型 ， 它 实际 上 是 一 个 Binder， 它 的 具体 实现 是 
ApplicationThread 和 ApplicationThreadNative， 在 9.2 广 已 经 对 这 个 问题 
做 了 说 明 。 由 于 ApplicationThread 继 厌 了 ApplicationThreadNative , 

此 只 需要 看 ApplicationThread 对 Service 局 动 过 程 的 处 理 即 可 ， 这 对 应 
着 它 的 scheduleCreateService 方 法 ， 如 下 所 示 。 


public final void scheduleCreateService(IBinder token, 
ServiceInfo info,CompatibilityInfo 
compatInfo,int processState) { 
updateProcessState(processState, false); 
CreateServiceData s = new CreateServiceData(); 
s.token = token; 
s.info = info; 
s.compatInfo = compatInfo; 


sendMessage(H.CREATE_SERVICE, s); 


很 显然 ， 这 个 过 程 和 Activity 的 局 动 过 程 是 类 似 的 ， 都 是 通过 发 送 
Te a H 来 完成 的 。H 会 接收 这 个 CREATE_SERVICE 消 息 并 通 
过 ActivityThread 的 handleCreateService 方 法 来 完成 Service 的 最 终局 动 ， 
handleCreateService 的 源码 如 下 所 示 。 


private void handleCreateService(CreateServiceData data) { 


// If we are getting ready to gc after going to the 


handleCreateService 主 要 完成 了 如 下 几 件 事 。 


首先 通过 类 加 载 器 创建 Service 的 实例 。 


然后 创建 Application 对 象 并 调用 其 onCreate， 当 然 Application 的 创 
mi 


接着 创建 ConTextImpl 对 象 并 通过 Service 的 attach 方 法 建立 二 者 之 
间 的 关系 ， 这 个 过 程 和 Activity 实 际 上 是 类 似 的 ， 毕 竟 Service 和 
Activity 都 是 一 个 Context ° 


最 后 调用 Service 的 onCreate 方 法 并 将 Service 对象 存 储 到 
ActivityThread 中 的 一 个 列表 中 。 这 个 列表 的 定义 如 下 所 示 。 


final ArrayMap<IBinder, Service> mServices = new 


ArrayMap<IBinder,Service>() 


由 于 Service 的 onCreate 方 法 被 执行 了 ， 这 也 意味 着 Service 已 经 局 
动 了 。 除 此 之 外 ，ActivityThread 中 还 会 通过 handleServiceArgs 方 法 调 
用 Service 的 onStartCommand 方 法 ， 如 下 所 示 。 


private void handleServiceArgs(ServiceArgsData data) { 
Service s = mServices.get(data.token); 
if (s != null) { 
try { 
if (data.args != null) { 


data.args.setExtrasClassLoader(s.getClassLoader()); 
data.args.prepareToEnterProcess(); 


‘i 


int res; 


到 这 里 ，S$ervice 的 启动 过 程 已 经 分 析 完 了 ， 下 面 分析 Service 的 绑 
定 过 程 。 


9.3.2 Service HH ELE 


和 Service 的 启动 过 程 一 样 ，Service 的 绑 定 过 程 也 是 从 
ContextWrapper 开 始 的 ， 如 下 所 示 。 


public boolean bindService(Intent service, ServiceConnection 
conn, 
int flags) { 


return mBase.bindService(service, conn, flags); 


个 过 程 和 Service 的 启动 过 程 是 类 似 的 ，mBase 同 样 是 
Ba 对 象 。ContextImpl 的 bindService 方 法 最 终 会 调用 目 
己 的 bindServiceCommon 方 法 ， 如 下 所 示 。 


private boolean bindServiceCommon(Intent 
service,ServiceConnection conn,int flags, 
UserHandle user) { 
IServiceConnection sd; 


if (conn == null) { 


mMainThread.getApplicationThread(),getActivityToken(), 


service, service.resolveTypeIfNeeded(getContentResolver()), 
sd, flags, user.getIdentifier()); 
if (res < 0) { 
throw new SecurityException( 
"Not allowed to bind to 
service " + service); 
} 
return res != 0; 
} catch (RemoteException e) { 


return false; 


bindServiceCommon 方 法 主要 完成 如 下 两 件 事情 。 


首先 将 客户 端的 ServiceConnection 对 和 象 转 化 为 
ServiceDispatcher.InnerConnection 对 象 。 之 所 以 不 能 直接 使 用 
ServiceConnection 对 象 ， 这 是 因为 服务 的 绑 定 有 可 能 是 跨 进 程 的 ， 
此 ServiceConnection 对 象 必须 借助 于 Binder 才 能 让 远程 服务 端 回调 自己 
的 方法 ， 而 ServiceDispatcher 的 内 部 类 InnerConnection 刚 好 充当 了 
Binder 这 个 角色 。 那么 ServiceDispatcher 的 作用 是 什么 呢 ? 其 实 
ServiceDispatcher 起 着 连接 ServiceConnection 和 InnerConnection 的 作 
用 。 这 个 过 程 由 LoadedApk 的 getServiceDispatcher 方 法 来 完成 ， 它 的 实 
现 如 下 : 


在 上 面 的 代码 中 ，mServices 是 一 个 ArrayMap ， 它 存储 了 一 个 应 用 
当前 活动 的 ServiceConnection 和 ServiceDispatcher 的 映射 关系 ， 它 的 定 
义 如 下 所 示 。 


private final 
ArrayMap<Context,ArrayMap<serviceConnection,LoadedApk.ServiceDi 
spatcher>> mServices = new ArrayMap<Context, ArrayMap 


<serviceConnection, LoadedApk.ServiceDispatcher>>(); 


系统 首先 会 查找 是 否 存 在 相同 的 ServiceConnection， 如 果 不 存 在 
就 重新 创建 一 个 ServiceDispatcher 对 象 并 将 其 存储 在 mServices 中 ， 其 中 
上 映射 关系 的 key 是 ServiceConnection ，value 是 ServiceDispatcher ， 在 
ServiceDispatcher 的 内 部 又 保存 了 ServiceConnection 和 InnerConnection 
对 象 。 当 Service 和 客户 端 建立 连接 后 ， 系 统 会 通过 InnerConnection 来 
调用 ServiceConnection 中 的 onServiceConnected 方 法 ， 这 个 过 程 有 可 能 
是 跨 进 程 的 。 当 ServiceDispatcher 创 建 好 了 以 后 ，getServiceDispatcher 
会 返回 其 保存 的 InnerConnection 对 和 象 。 


接着 bindServiceCommon 方 法 会 通过 AMS 来 完成 Service 的 具体 的 
绑 定 过 程 ， 这 对 应 于 AMS 的 bindService 方 法 ， 如 下 所 示 。 


public int bindService(IApplicationThread caller,IBinder 
token, 
Intent service, String resolvedType, 
IServiceConnection connection, int flags, int 
userId) { 
enforceNotIsolatedCaller("bindService"); 


// Refuse possible leaked file descriptors 


if (service != null && service.hasFileDescriptors() == 
true) { 
throw new IllegalArgumentException("File 
descriptors passed in Intent"); 
} 
synchronized(this) { 
return 
mServices.bindServiceLocked(caller,token, service, resolvedType, 


connection, flags, userId); 


fe PA, AMS A ActiveServices fH‘) bindServiceLocked 77 YË , 
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行 逻辑 和 9.3.1 广 中 的 逻辑 类 似 ， 最 终 都 是 通过 ApplicationThread 来 完 
成 Service 实 例 的 创建 并 执行 其 onCreate 方 法 ， 这 里 不 再 重复 讲解 了 。 
和 局 动 Service 不 同 的 是 ，Service 的 绑 定 过 程 会 调用 app.thread 的 
scheduleBindService 方 法， 这 个 过 程 的 实现 在 ActiveServices 的 
requestServiceBindingLocked 方 法 中 ， 如 下 所 示 。 


private final boolean 
requestServiceBindingLocked(ServiceRecord r, 
IntentBindRecord i,boolean execInFg,boolean 
rebind) { 
if (r.app == null || r.app.thread == null) { 


// If service is not currently running,can't 
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一 系列 以 schedule 开 头 的 方法 ， 其 内 部 都 是 通过 Handler HK RES, 
对 于 scheduleBindService 方 法 来 说 也 是 如 此 ， 它 的 实现 如 下 所 示 。 


public final void scheduleBindService(IBinder token,Intent 
intent, 
boolean rebind, int processState) { 
updateProcessState(processState, false); 
BindServiceData s = new BindServiceData(); 
s.token = token; 
s.intent = intent; 
s.rebind = rebind; 
if (DEBUG_SERVICE) 
Slog.v(TAG, "scheduleBindService token=" + token 
+ " antent=" + intent + " uld=" 
+ Binder.getCallingUid() + " 
pid=" + Binder.getCallingPid()); 


sendMessage(H.BIND_SERVICE, s); 


在 了 内 部 ， 接 收 到 BIND_ SERVICE 这 类 消息 时 ， 会 交 给 
ActivityThread 的 handleBind-Service 方 法 来 处 理 。 在 handleBindService 
中 ， 首 先 根 据 Service 的 token 取 出 Service 对 象 ， 然 后 调用 Service 的 
onBind 方 法 ，Service 的 onBind 方 法 会 返回 一 个 Binder 对 象 给 客户 端 使 
用 ， 这 个 过 程 我 们 在 Service 的 开发 过 程 中 应 该 都 比较 熟悉 了 。 原 则 上 
来 说 ，S$ervice 的 onBind 方 法 被 调用 以 后 ，Service 束 处 于 绑 定 状态 了 ， 


但 是 onBind 方 法 是 Service 的 方法 ， 这 个 时 候 客 户 端 并 不 知道 已 经 成 功 
连接 Service 了 ， 所 以 还 必须 调用 客户 端的 ServiceConnection 中 的 
onServiceConnected, jX "II FE ze H ActivityManagerNative.getDefault() 
的 publishService 方法 来 完成 的 ， 而 前 面 多 次 提 到 ， 
ActivityManagerNative.getDefaultO 就 是 AMS。handleBindService 的 实现 
过 程 如 下 所 示 。 


Service 有 一 个 特性 ， 当 多 次 绑 定 同一 个 Service 时 Service 的 
onBind 方 法 只 会 执行 一 次 ， 除 非 Service 被 终止 了 。 当 Service 的 onBind 
执行 以 后 ， 系 统 还 需要 告知 客户 端 已 经 成 功 连接 Service 了。 根据 上 面 
的 分 析 ， 这 个 过 程 由 AMS 的 publishService 方 法 来 实现 ， 它 的 源码 如 下 
所 示 。 


public void publishService(IBinder token, Intent 
intent,IBinder service) { 


// Refuse possible leaked file descriptors 


if (intent != null && intent.hasFileDescriptors() == 
true) { 
throw new IllegalArgumentException("File 
descriptors passed in Intent"); 
} 


synchronized(this) { 
if (!(token instanceof ServiceRecord)) { 
throw new 


IllegalArgumentException("Invalid service token"); 


i 


mServices.publishServiceLocked((ServiceRecord)token, intent, serv 


ice); 


从 上 面 代码 可 以 看 出 ，AMS 的 publishService 方 法 将 具体 的 工作 交 
给 了 ActiveServices 类 型 的 mServices 对 象 来 处 理 。ActiveServices 的 
publishServiceLocked 方 法 看 起 来 很 复杂 ， 但 其 实 核 心 代码 就 只 有 一 句 
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ConnectionRecord，c.conn 的 类 型 是 ServiceDispatcher.InnerConnection , 
service 束 是 Service 的 onBind 方 法 返回 的 Binder 对 象 。 为 了 分 析 具 体 的 逻 
辑 ， 下 面 看 一 下 ServiceDispatcher InnerConnection 的 定义 ， 如 下 所 示 。 


从 InnerConnection 的 定义 可 以 看 出 ， 它 的 connected 方 法 又 调用 了 
ServiceDispatcher 的 connected 方 法 ，ServiceDispatcher 的 connected 方 法 
的 实现 如 下 所 示 。 


对 于 Service 的 绑 定 过 程 来 说 ，ServiceDispatcher 的 mActivityThread 
ye — ® Handler, HS E Hi ActivityThread F AJH, M BY E 
ServiceDispatcher 的 创建 过 程 来 说 ，mActivityThread 不 会 为 null， 这 样 
一 来 ，RunConnection 就 可 以 经 由 HH 的 post 方 法 从 而 运行 在 主线 程 中 ， 
此 ， 客 户 端 ServiceConnection 中 的 方法 是 在 主线 程 被 回调 的 。 
RunConnection 的 定义 如 下 所 示 。 


final int mCommand; 


} 


很 E , RunConnection 的 mn 方法 也 是 简单 调用 了 
ServiceDispatcher 的 doConnected 方 法 ， 由 于 ServiceDispatcher 内 部 保存 
了 客户 端的 ServiceConnection I & , 此 它 可 以 很 方便 地 调用 
ServiceConnection 对 象 的 onServiceConnected 方 法 ， 如 下 所 示 。 


// If there is a new service, it is now connected. 
if (service != null) { 
mConnection.onServiceConnected(name, service); 


} 
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分 析 完 成 了 ， 至 于 Service 的 停止 过 程 和 解除 绑 定 的 过 程 ， 系 统 的 执行 
过 程 是 类 似 的 ， 读 者 可 以 目 行 分 析 源 码 ， 这 里 就 不 再 分 机 了 。 


9.4 BroadcastReceiver 的 工作 过 
程 


本 节 将 介绍 BroadcastReceiver 的 工作 过 程 ， 主 要 包含 两 方面 的 内 
容 ， 一 个 是 广播 的 注册 过 程 ， 另 一 个 是 广播 的 发 送 和 接收 过 程 。 这 里 
完 人 简单 回顾 一 下 广播 的 使 用 方法 ， 首 先 要 定义 广播 接收 者 ， 只 需要 继 
承 BroadcastReceiver 并 重 写 onReceive 方 法 即 可 ， 下 面 是 一 个 典型 的 广 
播 接收 者 的 实现 ; 


定义 好 了 广播 接收 者 ， 接 着 还 需要 注册 广播 接收 者 ， 注 册 分 为 两 
种 方式 ， 既 可 以 在 AndroidManifest 文 件 中 静态 注册 ， 也 可 以 通过 代码 
动态 注册 。 


静态 注册 的 示例 如 下 : 


通过 代码 来 动态 注册 广播 也 是 很 简单 的 ， 如 下 所 示 。 需 要 注意 的 
是 ， 动 态 注册 的 广播 需要 在 合适 的 时 机 进行 解 注册 ， 解 注册 采用 


unregisterReceiver 方 法 。 


IntentFilter filter = new IntentFilter(); 
filter.addAction("com.ryg.receiver.LAUNCH"); 


registerReceiver(new MyReceiver(), filter); 
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Intent intent = new Intent(); 
intent.setAction("com.ryg.receiver.LAUNCH"); 


sendBroadcast (intent); 


上 面 简单 回顾 了 广播 的 使 用 方法 ， 下 面 就 开始 分 析 广播 的 工作 过 
程 ， 首 先 分 析 广 播 的 注册 过 程 ， 接 着 再 分 析 广 播 的 发 送 和 接收 过 程 。 


9.4.1 广播 的 注册 过 程 


广播 的 注册 分 为 静态 注册 和 动态 注册 ， 其 中 静态 注册 的 广播 在 应 
用 安装 时 由 系统 目 动 完 成 注册 ， 有 具体 来 说 是 由 了 PMS 
(PackageManagerService) 来 完成 整个 注册 过 程 的 ， 除 了 广播 以 外 ， 
其 他 三 大 组 件 也 都 是 在 应 用 安装 时 由 PMS 解 析 并 注册 的 。 这 里 只 分 析 
广播 的 动态 注册 的 过 程 ， 动 态 注册 的 过 程 是 从 ContextWrapper 的 
registerReceiver 方法 开始 的 ， 和 Activity 以 及 Service — fF ° 
ContextWrapper 并 没有 做 实际 的 工作 ， 而 是 将 注册 过 程 直 接 交 给 
ContextImpl 来 完成 ， 如 下 所 示 。 


public Intent registerReceiver ( 


BroadcastReceiver receiver,IntentFilter filter) { 


ContextImpl 的 registerReceiver 方法 调用 了 自己 的 
registerReceiverInternal 方 法 ， 它 的 实现 如 下 所 示 。 


rd = new LoadedApk.ReceiverDispatcher ( 


receiver, context, scheduler, null, true).getIIntent-Receiver(); 


} 
} 
try { 


return 


ActivityManagerNative.getDefault().registerReceiver ( 
mMainThread.getApplicationThread(),mBasePackageName, 


rd, filter, broadcastPermission,userld); 
} catch (RemoteException e) { 


return null; 


在 上 面 的 代码 中 ， 系 统 首 先 从 mPackageInfo 获 取 IIntentReceiver 对 
象 ， 然 后 再 采用 路 进 程 的 方式 同 AMS 发 送 广播 注册 的 请 求 。 之 所 以 采 
用 ImtentReceiver 而 不 是 直接 采用 BroadcastReceiver， 这 是 因为 上 述 注 
册 过 程 是 一 个 进程 间 通 信 的 过 程 ， 而 BroadcastReceiver 作 为 Android 的 
一 个 组 件 是 不 能 直接 跨 进 程 传递 的 ， 所 以 需要 通过 IIntentReceiver 来 中 
转 一 下 。 训 无 疑问 ，ImtentReceiver 必 须 是 一 个 Binder 接 口 ， 它 的 具体 
实 现 是 LoadedApk.Receiver-Dispatcher.InnerReceiver 
ReceiverDispatcher 的 内 部 同时 保存 了 BroadcastReceiver 和 
InnerReceiver ， 这 样 当 接收 到 广播 时 ，ReceiverDispatcher 可 以 很 方便 
地 调用 BroadcastReceiver 的 onReceive 方 法 ， 具 体会 在 9.4.2 方 中 说 明 。 


可 以 发 现 ，BroadcastReceiver 的 这 个 过 程 和 Service 的 实现 原理 类 似 ， 
Service 也 有 一 个 HY ServiceDispatcher 的 类 ， 并 且 其 内 部 类 
InnerConnection 也 是 一 个 Binder 接 口 ， 作 用 同样 也 是 为 了 进程 间 通 信 ， 
这 一 点 在 9.3.2 市 中 已 经 描述 过 了 ， 这 里 不 再 重复 说 明 。 


X F ActivityManagerNative.getDefault() ， 这 里 就 不 用 再 做 说 明 
T, EBLEAMS, ， 在 前 面 的 章节 中 已 经 多 次 提 到 它 。 下 面 看 一 下 
ReceiverDispatcher 的 getIIntentReceiver 的 实现 ， 如 下 所 示 。 很 显然 ， 
getReceiverDispatcher 方 法 重新 创建 了 一 个 ReceiverDispatcher 对 象 并 将 
其 保存 的 InnerReceiver 对 象 作 为 返回 值 返回 ， 其 中 InnerReceiver 对 象 和 
BroadcastReceiver 都 是 在 ReceiverDispatcher 的 构造 方法 中 被 保存 起 来 
Hy > 


public IIntentReceiver 
getReceiverDispatcher(BroadcastReceiver r, 
Context context,Handler handler, 
Instrumentation instrumentation,boolean 
registered) { 
synchronized (mReceivers) { 


LoadedApk.ReceiverDispatcher rd = null; 


ArrayMap<BroadcastReceiver, LoadedApk.ReceiverDispatcher> map = 
null; 
if (registered) { 
map = mReceivers.get(context); 
if (map != null) { 


rd = map.get(r); 


由 于 注册 广播 的 真正 实现 过 程 是 在 AMS 中 ， 因 此 我 们 需要 看 一 下 
AMS 的 具体 实现 。AMS 的 registerReceiver 方 法 看 起 来 很 长 ， 其 实 关 键 
点 束 只 有 下 面 一 部 分 ， 最 终 会 把 远程 的 InnerReceiver 对 象 以 及 


IntentFilter 对 象 存储 起 来 ， 这 样 整个 广播 的 注册 过 程 就 完成 了 ， 代 码 如 
下 所 示 。 


public Intent registerReceiver(IApplicationThread 
caller,String callerPackage, 
IIntentReceiver receiver,IntentFilter filter,String 


permission, int userId) { 


mRegisteredReceivers.put(receiver.asBinder(),rl); 
BroadcastFilter bf = new 
BroadcastFilter(filter,rl,callerPackage, 
permission, callingUid, userId); 

rl.add(bf); 
if (!bf.debugCheck()) { 

Slog.w(TAG, "==> For Dynamic broadast"); 
} 


mReceiverResolver.addFilter(bf); 


9.4.2 广播 的 发 送 和 接收 过 程 


上 面 分 析 了 广播 的 注册 过 程 ， 可 以 发 现 注册 过 程 的 逻辑 还 是 比较 
简单 的 ， 下 面 来 分 析 广 播 的 发 送 和 接收 过 程 。 当 通过 send 方 法 来 发 送 
广播 时 ，AMS 会 查找 出 匹配 的 广播 接收 者 并 将 广播 发 送 给 它们 处 理 。 
广播 的 发 送 有 几 种 类 型 : 普通 广播 、 有 序 广播 和 粘性 广播 ， 有 序 广播 


和 粘性 广播 与 普通 广播 相 比 具有 不 同 的 特性 ， 但 是 它们 的 发 送 /接收 过 
程 的 流程 是 类 似 的 ， 因 此 这 里 只 分 析 普通 广播 的 实现 。 


广播 的 发 送 和 接收 ， 其 本 质 是 一 个 过 程 的 两 个 阶段 。 这 里 从 广播 
的 发 送 可 以 说 起 ， 广 播 的 发 送 仍然 开始 于 ContextWrapper 的 
sendBroadcast 方法 ， 之 所 以 不 是 Context ， 那 是 因为 Context 的 
sendBroadcast 是 一 个 抽象 方法 。 和 广播 的 注册 过 程 一 样 ， 
ContextWrapper 的 sendBroadcast 方 法 仍然 什么 都 不 做 ， 只 是 把 事情 交 给 
ContextImpl 去 处 理 ，ContextImpl 的 sendBroadcast 方 法 的 源码 如 下 所 
未。 


public void sendBroadcast(Intent intent) { 
warnIfCallingFromSystemProcess(); 
String resolvedType = 
intent.resolveTypeIfNeeded(getContentResolver()); 


try { 


intent.prepareToLeaveProcess(); 
ActivityManagerNative.getDefault().broadcastIntent( 
mMainThread.getApplicationThread(),intent, resolvedType, null, 
Activity.RESULT_OK, null, null, null, AppOpsManager .OP_NONE, false, f 
alse, 


getUserId()); 


} catch (RemoteException e) { 


从 上 面 的 代码 来 看 ，ContextImpl 也 是 几乎 什么 事 都 没 干 ， 它 直接 
回 AMS 发 起 了 一 个 异步 请 求 用 于 发 送 广播 。 因 此 ， 下 面 直接 看 AMS 对 
广播 发 送 过 程 的 处 理 ，AMS 的 broadcastIntent 方 法 的 源码 如 下 所 示 。 


public final int broadcastIntent(IApplicationThread caller, 
Intent intent,String 
resolvedType, IIntentReceiver resultTo, 
int resultCode,String resultData,Bundle map, 
String requiredPermission,int appOp, boolean 
serialized,boolean sticky,int userId) { 
enforceNotIsolatedCaller("broadcastIntent"); 
synchronized(this) { 
intent = verifyBroadcastLocked(intent); 
final ProcessRecord callerApp = 
getRecordForAppLocked(caller); 
final int callingPid = Binder.getCallingPid(); 
final int callingUid = Binder.getCallingUid(); 
final long origId = 
Binder.clearCallingIdentity(); 
int res = broadcastIntentLocked(callerApp, 
callerApp != null ? 
callerApp.info.packageName : null, 


intent, resolvedType, resultTo, 


resultCode, resultData, map, requiredPermission, appOp, serialized,s 
ticky, 
callingPid, callingUid, userId); 
Binder.restoreCallingIdentity(origId); 


return res; 


MEM MARE, broadcastIntentY# FA 7 broadcastIntentLocked 77 
法 ，AMS 的 broadcastIntentLocked 方 法 有 436 行 代码 ， 看 起 来 比较 复 
杂 “。 在 代码 最 开始 有 如 下 一 行 : 


// By default broadcasts do not go to stopped apps. 
intent.addFlags(Intent.FLAG_EXCLUDE_STOPPED_PACKAGES) ; 


这 表示 在 Android 5.0 中 ， 默 认 情 况 下 广播 不 会 发 送 给 已 经 停止 的 
NH, MA a 5.0, MAndroid 3.1 开 始 广播 已 经 具有 这 
种 特性 了 。 这 是 因为 系统 在 Android 3.1 中 为 Intent 添 加 了 两 个 标记 位 ， 
分 HI Æ FLAG INCLUDE_STOPPED PACKAGES fill 
FLAG_EXCLUDE_STOPPED_PACKAGES， 用 来 控制 广播 是 否 要 对 处 
于 停止 状态 的 应 用 起 作用 ， 它 们 的 含义 如 下 所 示 。 


FLAG INCLUDE_STOPPED PACKAGES 


表示 包含 已 经 停止 的 应 用 ， 这 个 时 候 广 播 会 发 送 给 已 经 停止 的 应 
用 。 


FLAG_EXCLUDE_STOPPED_PACKAGES 


表示 不 包含 已 经 停止 的 应 用 ， 这 个 时 候 广播 不 会 发 送 给 已 经 停止 
的 应 用 。 


从 Android 3.1 开 始 ， 系 统 为 所 有 广播 默认 添加 了 
FLAG_EXCLUDE_STOPPED_PACKAGES 标 志 ， 这 样 做 是 为 了 防止 广 
播 无 意 间 或 者 在 不 必要 的 时 候 调 起 已 经 停止 运行 的 应 用 。 如 果 的 确 需 
要 调 起 未 局 动 的 应 用 ， 那 么 只 需要 为 广播 的 Intent 添加 
FLAG_INCLUDE_STOPPED_PACKAGES 标记 E 可 。 当 
FLAG_EXCLUDE_STOPPED_PACKAGES 和 
FLAG_INCLUDE_STOPPED_PACKAGES 两 种 标记 位 共存 时 ， 以 
FLAG INCLUDE_STOPPED_ PACKAGES 为 准 。 这 里 需要 补充 一 下 ， 
一 个 应 用 处 于 停止 状态 分 为 两 种 情形 : 第 一 种 是 应 用 安装 后 未 运行 ， 
第 二 种 是 应 用 被 手动 或 者 其 他 应 用 强 停 了 。Android 3.1 中 广播 的 这 个 
特性 同样 会 影响 开机 广播 ， 从 Android 3.1 开 始 ， 处 于 停止 状态 的 应 用 
同样 无 法 接收 到 开机 广播 ， 而 在 Android 3.1 之 前 ， 处 于 停止 状态 的 应 
用 是 可 以 收 到 开机 广播 的 。 


在 broadcastIntentLocked 的 内 部 ， 会 根据 intent-filter 碍 找 出 匹配 的 
广播 接收 者 并 经 过 一 系列 的 条 件 过 滤 ， 最 终 会 将 满足 条 件 的 广播 接收 
者 添加 a 到 BroadcastQueue 中 ， 接 着 BroadcastQueue 束 会 将 广播 发 送 给 相 
应 的 广播 接收 者 ， 这 个 过 程 的 源码 如 下 所 示 。 


if ((receivers != null && receivers.size() > 0) 
|| resultTo != null) { 
BroadcastQueue queue = broadcastQueueForIntent(intent); 
BroadcastRecord r = new 


BroadcastRecord(queue, intent,callerApp, 


下 面 看 一 下 BroadcastQueue 中 广播 的 发 送 过 程 的 实现 ， 如 下 所 


AN 


+ mBroadcastsScheduled) ; 
if (mBroadcastsScheduled) { 


return; 


mHandler .sendMessage(mHandler .obtainMessage(BROADCAST_INTENT_MS 
G,this)); 


mBroadcastsScheduled = true; 


BroadcastQueue 的 scheduleBroadcastsLocked 方 法 并 没有 立即 发 送 广 
播 ， 而 是 发 送 了 一 个 BROADCAST _INTENT_MSG 类 型 的 消息 ， 
BroadcastQueue 收 到 消息 后 会 调用 process-NextBroadcast 方 法 ， 
BroadcastQueue 的 processNextBroadcast 方 法 对 普通 广播 的 处 理 如 下 所 
示 。 


// First,deliver any non-serialized broadcasts right away. 
while (mParallelBroadcasts.size() > 0) { 

r = mParallelBroadcasts.remove(0); 

r.dispatchTime = SystemClock.uptimeMillis(); 

r.dispatchClockTime = System.currentTimeMillis(); 

final int N = r.receivers.size(); 

if (DEBUG_BROADCAST_LIGHT) Slog.v(TAG, "Processing 
parallel broadcast [" 
+ mQueueName + "] " + r); 
for (int i=0; i<N; i++) { 


Object target = r.receivers.get(i); 


if (DEBUG_BROADCAST) Slog.v(TAG, 
"Delivering non-ordered on["+mQueueName 
+ "] to registered " 
+ target + "E 
deliverToRegisteredReceiverLocked(r, 
(BroadcastFilter)target,false); 
} 
addBroadcastToHistoryLocked(r); 
if (DEBUG_BROADCAST_LIGHT) Slog.v(TAG,"Done with 
parallel broadcast [" 


+ mQueueName + "] " + r); 


可 以 看 到 ， 无 序 广 播 存 储 在 mParallelBroadcasts 中 ， 系 统 会 壳 历 
mParallelBroadcasts 并 将 其 中 的 广播 发 送 给 它们 所 有 的 接 收 者 具体 的 
发 送 过 程 是 通过 deliverToRegistered-ReceiverLocked 方 法 来 实现 的 。 
deliverToRegisteredReceiverLocked 方 法 负责 将 一 个 广播 发 送 给 一 个 特 
定 的 接收 者 ， 它 内 部 调用 了 performReceiveLocked 方 法 来 完成 具体 的 发 
AE: 


performReceiveLocked(filter.receiverList.app, filter.receiverLis 
t.receiver, 
new Intent(r.intent),r.resultCode,r.resultData, 


r.resultExtras,r.ordered,r.initialSticky,r.userId); 


performReceiveLocked 方 法 的 实现 如 下 所 示 。 由 于 接收 广 li 
应 用 程序 ， 因 此 app.thread 不 为 null， 根 据 前 面 的 分 析 我 们 知道 这 里 的 


app.thread 仍 然 指 ApplicationThread 。 


ApplicationThread 的 scheduleRegisteredReceiver 的 实现 比较 简单 ， 
它 通 过 InnerReceiver 来 实现 广播 的 接收 ， 如 下 所 示 。 


InnerReceiver 的 performReceive J 法 会 调 用 
LoadedApk.ReceiverDispatcher #)  perform-Receive J 法 ， 
LoadedApk.ReceiverDispatcher 的 performReceive 方 法 的 实现 如 下 所 示 。 


在 上 面 的 代码 中 ， 会 创建 一 个 Args 对 象 并 通过 mActivityThread 的 
post 方法 来 执行 Args 中 的 逻辑 ， 而 Args 实 现 了 Runnable 接 口 。 


mActivityThreadx: “Handler, EXA HE ActivityThread'F #JmH, 
ae AE 是 ActivityIThread 的 内 部 类 再 ， 关 于 了 H 这 个 类 前 面 已 经 介绍 过 
了 ， 这 里 就 不 再 多 说 了。 在 Args 的 run 方 法 中 有 如 下 几 行 代码 : 


final BroadcastReceiver receiver = mReceiver; 
receiver.setPendingResult(this); 


receiver.onReceive(mContext,intent); 


很 显然 ， 这 个 时 候 BroadcastReceiver 的 onReceive 方 法 被 执行 了 ， 
也 束 是 说 应 用 已 经 接收 到 广播 了 ， 同 时 onReceive 方 法 是 在 广播 接收 者 
的 主线 程 中 被 调用 的 。 到 这 里 ， 整 个 广播 的 注册 、 发 送 和 接收 过 程 已 
经 分 析 完 了 ， 读 者 应 该 对 广播 的 整个 工作 过 程 有 了 一 定 的 理解 。 


9.5 ”ContentProvider 的 工作 过 程 


ContentProvider 的 使 用 方法 在 第 2 章 已 经 做 了 介绍 ， 这 里 再 简单 说 
明 一 下 。ContentProvider 是 一 种 内 容 共享 型 组 件 ， 它 通过 Binder 同 其 他 
组 件 力 至 其 他 应 用 提供 数据 。 当 ContentProvider 所 在 的 进程 启动 时 ， 
ContentProvider 会 同时 局 动 并 被 发 布 到 AMS 中 。 需 要 注意 的 是 ， 这 个 
时 候 ContentProvider 的 onCreate 要 先 于 Application 的 onCreate 而 执行 ， 
这 在 四 大 组 件 中 是 一 个 少 有 的 现象 。 


当 一 个 应 用 启动 时 ， 入 口 方法 为 ActivityThread 的 main 方 法 ，main 
方法 是 一 个 静态 方法 ， 在 main 方 法 中 会 创建 ActivityThread 的 实例 并 创 
建 主线 程 的 消 轧 队列 ， 然 后 在 ActivityThread 的 attach 方 法 中 会 远程 调用 
AMS 的 attachApplication 方 法 并 将 en 象 提供 给 AMS 。 
ApplicationThread 是 D Binder X % , CHM Binder 接口 是 


IApplicationThread， 它 主要 用 于 ActivityThread 和 AMS 之 间 的 通信 ， 这 
一 点 在 前 面 多 次 提 到 。 在 AMS 的 attachApplication 方 法 中 ， 会 调用 
ApplicationThread 的 bindApplication 方 法 ， 注 意 这 个 过 程 同 样 是 跨 进 程 
完成 的 ，bindApplication 的 逻辑 会 经 过 ActivityThread 中 的 mH Handler 
切换 到 ActivityThread 中 去 执行 ， 具 体 的 方法 是 handleBindApplication ° 
在 handleBindApplication 方 法 中 ，ActivityThread 会 创建 Application 对 象 
并 加 载 ContentProvider。 需 要 注意 的 是 ，ActivityThread 会 移 加 载 
ContentProvider， 然 后 再 调用 Application 的 onCreate 方 法 ， 整 个 流程 可 
以 参看 图 9-2 > 
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图 9-2 ”ContentProvider 的 启动 过 程 


这 就 是 ContentProvider 的 启动 过 程 ，ContentProvider 启 动 后 ， 外 办 
束 可 以 通过 它 所 提供 的 增删 改 查 这 四 个 接口 来 操作 ContentProvider 中 
的 数据 源 ， 即 insert、delete、update 和 query 四 个 方法 。 这 四 个 方法 都 
是 通过 Binder 来 调用 的 ， 外 界 无 法 直接 访问 ContentProvider， 它 只 能 通 
过 AMS 根据 Uri 来 获取 对 应 的 ContentProvider 的 Binder 接口 


IConentProvider ， 然 后 再 通过 IConentProvider 来 访问 ContentProvider 中 
的 数据 源 。 


一 般 来 说 ，ContentProvider 都 应 该 是 单 实例 鸭 。ContentProvider 到 | 
底 是 不 是 单 实 例 ， 这 是 由 它 的 android:multiprocess 属 性 来 决定 的 ， 当 
android:multiprocessAfalseH, ，ContentProvider 是 单 实例 ， 这 也 是 默认 
值 ， 当 android:multiprocess 为 true 有 时 ，ContentProvider 为 多 实例 ， 这 个 
时 候 在 每 个 调用 者 的 进程 中 都 存在 一 个 ContentProvider 对 象 。 由 于 在 
实际 的 开发 中 ， 并 未 发 现 多 实例 的 ContentProvider 的 具体 使 用 场景 ， 
官方 文档 中 的 解释 是 这 样 可 以 避免 进程 间 通 信 的 开销 ， 但 是 这 在 实际 
开发 中 仍然 缺少 使 用 价值 。 因 此 ， 我 们 可 以 简单 认为 ContentProvider 
都 是 单 实例 的 。 下 面 分 析 单 实例 的 ContentProvider 的 启动 过 程 。 


访问 ContentProvider 需 要 通过 ContentResolver ，ContentResolver 是 
一 个 抽象 类 ， 通 过 Context 的 getContentResolver 方 法 获取 的 实际 上 是 
ApplicationContentResolver 对 象 ，ApplicationContentResolver 类 继承 了 
ContentResolver 并 实 现 了 ContentResolver 的 抽象 方法 。 当 
ContentProvider 所 在 的 进程 未 启动 时 ， 第 一 次 访问 它 时 残 会 触发 
ContentProvider 的 创建 ， 当 然 这 也 伴随 着 a 在 进程 的 局 
动 。 通 过 ContentProvider A 个 方法 的 任何 一 个 都 可 以 触发 
ContentProvider 的 启动 过 程 ， 这 里 选择 query 方 法 。 


ContentProvider 的 query 方 法 中 ， 首 先 会 获取 IContentProvider 
象 ， 不 管 是 通过 acquireUnstableProvider 方法 还 是 和 直 y 通 
acquireProvider 方 法 ， 它 们 的 本 质 都 是 一 样 的 ， 最 终 都 是 通 
acquireProvider 方 法 来 获取 ContentProvider。 下 面 Ai 
Resolver 的 acquireProvider 方 法 的 具体 实现 : 


protected IContentProvider acquireProvider (Context 
context,String auth) { 


return mMainThread.acquireProvider(context, 


ContentProvider.getAuthorityWithoutUserId(auth), 


resolveUserIdFromAuthority(auth), true); 


ApplicationContentResolver 的 acquireProvider 方 法 并 没有 处 理 任 何 
逻辑 ， 它 直接 调用 了 ActivityThread 的 acquireProvider 方法 ， 
ActivityThread 的 acquireProvider 方 法 的 源码 如 下 所 示 。 


public final IContentProvider acquireProvider ( 
Context c,String auth,int userId, boolean 
stable) { 
final IContentProvider provider = 
acquireExistingProvider(c, auth, userId, stable); 
if (provider != null) { 


return provider; 


// There is a possible race here. Another thread may 
try to acquire 
// the same provider at the same time. When this 
happens,we want to ensure 
// that the first one wins. 
// Note that we cannot hold the lock while acquiring 


and installing the 


上 面 的 代码 首先 会 从 ActivityThread 中 查找 是 否 已 经 存在 目标 
ContentProvider 了 ， 如 果 存 在 就 直接 返回 。ActivityThread 中 通过 
mProviderMap 来 存储 已 经 启动 的 ContentProvider 对 象 ，mProviderMap 
的 声明 如 下 所 示 。 


final ArrayMap<providerKey, ProviderClientRecord> 
mProviderMap 


= new ArrayMap<providerKey,ProviderClientRecord>(); 


WR H El ContentProvider?% A aa, AS Aw AIA — AE lA] ts OK 
给 AMS 让 其 启动 目标 ContentProvider ， 最 后 再 通过 installProvider 方 法 
来 修改 引用 计数 。 那 么 AMS 是 如 何 启动 ContentProvider 的 呢 ? 我 们 知 
道 ，ContentProvider 被 司 动 时 会 伴随 着 进程 的 司 动 ， 在 AMS 中 ， 首 移 
会 启动 ContentProvider 所 在 的 进程 ， 然 后 再 启动 ContentProvider。 启动 
进程 是 由 AMS 的 startProcessLocked 方 法 来 完成 的 ， 其 内 部 主要 是 通过 
Process 的 start 方 法 来 完成 一 个 新 进程 的 启动 ， 狐 进程 启动 后 其 入 口 方 
法 为 ActivityThread 的 main 方 法 ， 如 下 所 示 。 


public static void main(String[] args) { 
SamplingProfilerIntegration.start(); 
// CloseGuard defaults to true and can be quite spammy. 
We 
// disable it here,but selectively enable it later (via 
// StrictMode) on debug builds,but using DropBox, not 
logs. 
CloseGuard.setEnabled(false); 
Environment.initForCurrentUser(); 


// Set the reporter for event logging in libcore 


可 以 看 到 ，ActivityThread 的 main 方 法 是 一 个 静态 方 E 在 它 内 部 
首先 会 创建 Activity-Thread 的 实例 并 调用 attach 方 法 来 进行 一 系列 初始 
化 ， 接 着 束 开始 进行 消息 循环 了 。ActivityThread attach 方 法 会 将 
ApplicationThread 对 象 通过 AMS 的 attachApplication 方 法 跨 进 程 传递 给 
AMS， 最 终 AMS 会 完成 ContentProvider 的 创建 过 程 ， 源 码 如 下 所 示 。 


try { 
mgr.attachApplication(mAppThread); 
} catch (RemoteException ex) { 


// Ignore 


AMS 的 attachApplication 方 法 调用 了 attachApplicationLocked 方 法 ， 
attachApplication-Locked 中 X Yi 用 了 ApplicationThread 的 
bindApplication， 注 意 这 个 过 程 也 是 进程 间 调 用 ， 如 下 所 示 。 


thread.bindApplication(processName, appInfo,providers,app.instru 


men- tationClass, 


profilerInfo,app.instrumentationArguments, app.instrumentation- 


Watcher, 


app.instrumentationUiAutomationConnection, testMode, enableOpen- 
GlTrace, 

isRestrictedBackupMode || 
InormalMode, app.persistent, 


new 


Configuration(mConfiguration),app.compat, getCommonServices- 


Locked(), 


mCoreSettingsObserver .getCoreSettingsLocked()); 


ActivityThread 的 bindApplication 会 发 送 一 个 BIND_APPLICATION 
类 型 的 消息 给 mH ，mH 是 一 个 Handler， 它 收 到 消息 后 会 调用 
ActivityThreadAJhandleBindApplication 7 Y, bindApplication X 1495 4 
的 过 程 如 下 所 示 。 


AppBindData data = new AppBindData(); 


data. 
data. 
data. 
data. 
data. 
data. 


processName = processName; 


appInfo = appInfo; 

providers = providers; 

instrumentationName = instrumentationName; 
instrumentationArgs = instrumentationArgs; 
instrumentationWatcher = instrumentationWatcher; 


data.instrumentationUiAutomationConnection = 


instrumentationUiConnection; 


data. 
data. 
data. 
data. 
data. 
data. 
data. 


debugMode = debugMode; 

enableOpenGlTrace = enableOpenGlTrace; 
restrictedBackupMode = isRestrictedBackupMode; 
persistent = persistent; 

config = config; 

compatInfo = compatInfo; 


initProfilerInfo = profilerInfo; 


sendMessage(H.BIND_APPLICATION, data); 


ActivityThread 的 handleBindApplication 则 完成 了 Application 的 创建 
以 及 Content-Provider 的 创建 ， 可 以 分 为 如 下 四 个 步骤 。 


1. 创建 ContextImpl 和 JInstrumentation 


2. 创建 Application 对 象 


Application app = 
data.info.makeApplication(data.restrictedBackupMode, null); 


mInitialApplication = app; 


3. 启动 当前 进程 的 ContentProvider 并 调用 其 onCreate 方 法 


List<providerInfo> providers = data.providers; 
if (providers != null) { 
installContentProviders(app, providers); 
// For process that contains content providers,we want 
to 
// ensure that the JIT is enabled "at some point". 


mH.sendEmptyMessageDelayed(H.ENABLE_JIT,10*1000); 


installContentProviders 完 成 了 ContentProvider 的 启动 工作 ， 它 的 实 
现 如 下 所 示 。 首 先 会 过 历 当 前 进程 的 ProviderInfo 的 列表 并 一 一 调用 调 
用 installProvider 方 法 来 启动 它们 ， 接 着 将 已 经 局 动 的 ContentProvider 发 
布 到 AMS 中 ，AMS 会 把 它们 存储 在 ProviderMap 中 ， 这 样 一 来 外 部 调 
用 者 天 可 以 直接 从 AMS 中 获取 ContentProvider 了 。 


private void installContentProviders( 
Context context, List<providerInfo> providers) { 
final ArrayList<IActivityManager .ContentProviderHolder> 
results = 
new 
ArrayList<IActivityManager.ContentProviderHolder>(); 


for (ProviderInfo cpi : providers) { 


下 面 看 一 下 ContentProvider 对 象 的 创建 过 程 ， 在 installProvider 方 法 
中 有 下 面 一 段 代 码 ， 其 通过 类 加 载 右 完成 了 ContentProvider 对 象 的 创 
EE: 


final java.lang.ClassLoader cl = c.getClassLoader(); 

localProvider = (ContentProvider)cl. 
loadClass(info.name).newInstance(); 

provider = localProvider.getIContentProvider(); 

if (provider == null) { 

Slog.e(TAG, "Failed to instantiate class " + 
info.name + " from sourceDir " + 
info.applicationInfo.sourceDir); 

return null; 

} 
if (DEBUG_PROVIDER) Slog.v( 

TAG, "Instantiating local provider " + info.name); 

// XXX Need to create the correct context for this 
provider. 


localProvider.attachInfo(c,info); 


在 上 述 代 码 中 ， 除 了 完成 ContentProvider 对 象 的 创建 ， 还 会 通过 
ContentProvider 的 attachInfo 方 法 来 调用 它 的 onCreate 方 法 ， 如 下 所 示 。 


private void attachInfo(Context context,ProviderInfo 


info,boolean testing) { 


if (mContext == null) { 


mContext = context; 


到 此 为 止 ，ContentProvider 已 经 被 创建 并 且 其 onCreate 方 法 也 已 经 
被 调用 ， 这 意味 着 ContentProvider 已 经 启动 完成 了 ° 


4. 调用 Application 的 onCreate 方 法 


经 过 上 面 的 四 个 步骤 ，ContentProvider 已 经 成 功 局 动 ， 并 且 其 所 
在 进程 的 Application 也 已 经 启动， 这 意味 着 ContentProvider 所 在 的 进程 
已 经 完成 了 整个 的 启动 过 程 ， 然 后 其 他 应 用 束 可 以 通过 AMS 来 访问 这 
个 ContentProvider 『。 拿 到 了 ContentProvider 以 后 ， 束 可 以 通过 它 所 提 
供 的 接口 方法 来 访问 它 了 。 需 要 注意 的 是 ， 这 里 的 ContentProvider 并 
不 是 原始 的 ContentProvider， 而 是 ContentProvider 的 Binder 类 型 的 对 象 
IContentProvider ，IContentProvider 的 具体 实现 是 ContentProviderNative 
和 ContentProvider.Transport , 其 中 ContentProvider. Transport 继承 了 
ContentProviderNative。 这 里 仍然 选择 query 方 法 ， 首 先 其 他 应 用 会 通 
过 AMS 获取 到 ContentProvider 的 Binder 对 象 即 IContentProvider ， 而 
IContentProvider 的 实现 者 实际 上 是 ContentProvider.Transport。 因此 其 
他 应 用 调用 IContentProvider 的 query 方 法 时 最 终 会 以 进程 间 通 信 的 方式 
调用 到 ContentProvider Transport 的 query 方 法 ， 它 的 实现 如 下 所 示 。 


public Cursor query(String callingPkg,Uri uri,String[ ] 
projection, 
String selection,String[] selectionArgs, String 
sortOrder, 
ICancellationSignal cancellationSignal) { 
validateIncomingUri(uri); 
uri = getUuriwithoutUserld(uri); 
if (enforceReadPermission(callingPkg,uri) != 
AppOpsManager .MODE_ALLOWED) { 
return 


rejectQuery(uri, projection, selection, selectionArgs, sortOrder, 


CancellationSignal.fromTransport(cancellationSignal)); 


很 显然 ， ContentProvider.Transport 的 query 方法 调用 了 
ContentProvider 的 query 方 法 ，query 方 法 的 执行 结果 再 通过 Binder 返 回 
给 调用 者 ， 这 样 一 来 整个 调用 过 程 束 完成 了 。 除 了 query 方 法 ，insert、 
delete 和 update 方 法 也 是 类 似 的 ， 这 里 就 不 再 分 析 了 。 


第 10 章 Android 的 消息 机 制 


本 章 所 要 讲述 的 内 容 是 Android 的 消 息 机 制 。 提 到 消息 机 制 读者 应 
该 都 不 卫生， 在 日 常 开 发 中 不 可 避免 地 要 涉及 这 方面 的 内 容 。 从 开发 
的 角度 米 说 ，Handler 是 Android 消 轧机 制 的 上 层 接口 ， 这 使 得 在 开发 
过 程 中 只 需要 和 Handler 交 互 即 可 。Handler 的 使 用 过 程 很 徐 单 ， 通 过 它 
可 以 轻松 地 将 一 个 任务 切换 到 Handler 所 在 的 线程 中 去 执行 。 很 多 人 认 
为 Handler 的 作用 是 更 新 UI， 这 的 确 没 错 ， 但 是 更 狐 UI 仅 仅 是 Handler 
的 一 个 特殊 的 使 用 场景 。 具 体 来 说 是 这 样 的 : 有 时 候 需 要 在 子 线程 中 
进行 耗 时 的 IO 操作 ， 可 能 是 读 取 文件 或 者 访问 网 络 等 ， 当 耗 时 操作 完 
成 以 后 可 能 需要 在 UI 上 做 一 些 改变 ， 由 于 Android 开 发 规范 的 限制 ， 我 
们 并 不 能 在 子 线程 中 访问 UI 控件 ， 否 则 束 会 触发 程序 异常 ， 这 个 时 候 
通过 Handler 就 可 以 将 更 新 UI 的 操作 切换 到 主线 程 中 执行 。 因 此 ， 本 质 
上 来 说 ，Handler 并 不 是 专门 用 于 更 新 UI 的 ， 它 只 是 常 补 开发 者 用 来 更 
新 UI。 


Android 的 消息 机 制 主要 是 指 Handler 的 运行 机 制 ，Handler 的 运行 
需要 展 层 的 MessageQueue 和 Looper 的 文 撑 。MessageQueue 的 中 文 翻译 
EKANI, MEE, CANF T KE, AMIERT 
外 提供 插入 和 删除 的 工作 。 虽 然 叫 消息 队列 ， 但 是 它 的 内 部 存储 结构 
并 不 是 真正 的 队列 ， 而 是 采用 单 链 表 的 数据 结构 来 存储 消息 列表 。 
Looper 的 中 文 翻译 为 循环 ， 在 这 里 可 以 理解 为 消息 循环 。 由 于 
MessageQueue 只 是 一 个 消息 的 存储 单元 ， 它 不 能 去 处 理 消息 ， 而 
Looper 就 填补 了 这 个 功能 ，Looper 会 以 无 限 循环 的 形式 去 查找 是 否 有 
源 消 息 ， 如 果 有 的 话 就 处 理 消息 ， 否 则 就 一 直 等 待 着 。Looper 中 还 有 


一 个 特殊 的 概念 ， 那 就 是 ThreadLocal，ThreadLocal 并 不 是 线程 ， 它 的 
作用 是 可 以 在 每 个 线程 中 存储 数据 。 我 们 知道 ，Handler 创 建 的 时 候 会 
采用 当前 Pliocene e MAS, #8 A Handler Hp Un fa) 5k 
取 到 当前 线程 的 Looper 呢 ?这 就 要 使 用 ThreadLocal T, ThreadLocal#] 
以 在 不 同 的 线程 中 互 不 干扰 地 存储 并 提供 数据 ， 通 过 ThreadLocal 可 以 
轻松 获取 每 个 线程 的 Looper。 当 然 需 要 注意 的 是 ， 线 程 是 默认 没有 
Looper 的 ， 如 果 和 需要 使 用 Handler 就 必须 为 线程 创建 Looper。 我 们 经 常 
提 到 的 主线 程 ， 也 叫 UI 线 程 ， 它 束 是 ActivityThread，ActivityThread 被 
创建 时 职 会 初始 化 Looper， 这 也 是 在 主线 程 中 默认 可 以 使 用 Handler 的 
原因 。 


10.1 Android 的 消息 机 制 概述 


前 面 提 到 ，Android 的 消息 e nd 以 及 
Handler 所 附带 的 MessageQueue 和 Looper 的 工作 过 程 ， 三 者 实际 上 和 是 
一 个 整体 ， 只 不 过 我 们 在 开发 过 程 中 eae ae ae 
Handler 的 主要 作用 是 将 一 个 任务 切换 到 某 个 指定 的 线程 中 去 执行 ， 那 
么 Android 为 什么 要 提供 这 个 功能 呢 ? 或 者 说 Android 为 什么 需要 提供 
在 某 个 具体 的 线程 中 执行 任务 这 种 功能 呢 ? 这 是 因为 Android 规 定 访问 
UI 只 能 在 主线 程 中 进行 ， 如 果 在 子 线程 中 访问 UI， 那 么 程序 就 会 抛 出 
异常 。ViewRootImpl 对 UI 操作 做 了 验证 ， 这 个 验证 工作 是 由 
ViewRootImpl 的 checkThread 方 法 来 完成 的 ， 如 下 所 示 。 


void checkThread() { 
if (mThread != Thread.currentThread()) { 


throw new CalledFromwWrongThreadException("Only 


the original thread that created a view hierarchy can touch its 
views."); 
i 
} 


EH checkThread iE FIOM RA, ER RAEN A PAR 
经 遇 到 过 。 由 于 这 一 点 的 限制 ， 导 致 必须 在 主线 程 中 访问 UI， 但 是 
Android 又 建议 不 要 在 主线 程 中 进行 耗 时 操作 ， 否 则 会 导致 程序 无 法 响 
应 即 ANR。 考 虑 一 种 情况 ， 假 如 我 们 需要 从 服务 端 拉 取 一 些 信 息 并 将 
其 显示 在 UI 上 ， 这 个 时 候 必 须 在 子 线程 中 进行 拉 取 工作 ， 拉 取 完 毕 后 
又 不 能 在 子 线程 中 直接 访问 UI， 如 果 没 有 Handler， 那 么 我 们 的 确 没有 
办 法 将 访问 UI 的 工作 切换 到 主线 程 中 去 执行 。 因 此 ， 系 统 之 所 以 提供 
Handler， 主 要 原因 丈 是 为 了 解决 在 子 线程 中 无 法 访问 UI 的 矛盾 。 


这 里 再 延伸 一 点 ， 系 统 为 什么 不 允许 在 子 线程 中 访问 UI 昵 ? IE 
因为 Android 的 UI 控件 不 是 线程 安全 的 ， 如 果 在 多 线程 中 并 发 访问 可 能 
会 导致 UI 控件 处 于 不 可 预期 的 状态 ， 那 为 什么 系统 不 对 UI 控件 的 访问 
加 上 锁 机 制 呢 ? 缺点 有 两 个 ， 首先 加 上 锁 机 制 会 让 UI 访问 的 逻辑 变 得 
复杂 ; 其 次 锁 机 制 会 降低 UI 访问 的 效率 ， 因 为 锁 机 制 会 阻塞 某 些 线程 
的 执行 。 鉴 于 这 两 个 缺点 ， 最 简单 且 融 效 的 方法 就 古 采用 单线 程 模型 
来 处 理 UI 操 作 ， 对 于 开发 者 来 说 也 不 是 很 麻烦 ， 只 征 需要 通过 Handler 
切换 一 下 UI 访问 的 执行 线程 即 可 。 


Handler 的 使 用 方法 这 里 就 不 做 介绍 了 了， 这 里 摘 述 一 下 Handler 的 工 
作 原 理 。Handler 创 建 时 会 采用 当前 线程 的 Looper 来 构建 内 部 的 消息 循 
AG, WHS AAG Looper, PARSE, UR Ata ° 


E/AndroidRuntime(27568): FATAL EXCEPTION: Thread-43484 
E/AndroidRuntime(27568): java.lang.RuntimeException: Can't 
create handler inside thread that has not called 
Looper.prepare() 
E/AndroidRuntime(27568): at android.os.Handler.<init> 
(Handler.java:121) 
E/AndroidRuntime (27568): at com.ryg.chapter_ 


10.TestActivity$3.run(TestActivity.java:57) 


如 何 解决 上 述 问 题 呢 ? ESB, AREAS BAS ONE 
Looper 即 可 ， 或 者 在 一 个 有 Looper 的 线程 中 创建 Handler 也 行 ， 具 体会 
在 10.2.3 世 中 进行 介绍 。 


Handler 创 建 完毕 后 ， 这 个 时 候 其 内 部 的 Looper 以 及 MessageQueue 
束 可 以 和 Handler 一 起 协同 工作 了 ， 然 后 通过 Handler 的 post 方 法 将 一 个 
Runnable 投 递 到 Handler 内 部 的 Looper 中 去 处 理 ， 也 可 以 通过 Handler 的 
send iERIK— NEN, IX AIRES Looper? KANE o ESL post 
方法 最 终 也 是 通过 send 方 法 来 完成 的 ， 接 下 来 主要 来 看 一 下 send 方 法 
的 工作 过 程 。 当 Handler 的 send 方 法 被 调用 时 ， 它 会 调用 MessageQueue 
的 enqueueMessage 方 法 将 这 个 消息 放 入 请 息 队列 中 ， 然 后 Looper 发 现 
有 新 消息 到 来 时 ， 残 会 处 理 这 个 消息 ， 最 终 消 息 中 的 Runnable 或 者 
Handler 的 handleMessage 方 法 残 会 被 调用 。 注 意 Looper 是 运行 在 创建 
Handler 所 在 的 线程 中 的 ， 这 样 一 来 Handler 中 的 业务 逻辑 束 被 切换 到 创 
建 Handler 所 在 的 线程 中 去 执行 了 ， 这 个 过 程 可 以 用 图 10-1 来 表示 。 
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Message 
Handler Message 


Message 
Message 


Looper 


Thread 1 Thread 2 


图 10-1 Handler 的 工作 过 程 


10.2 ” Android 的 消息 机 制 分 析 


在 10.1 方 中 对 Android 的 消息 机 制 已 经 做 了 一 个 概括 性 的 撞 述 ， 通 
过 图 10-1 也 能 够 比较 好 地 理解 Handler 的 工作 过 程 。 本 下 将 对 Android 消 
居 机 制 的 实现 原理 做 一 个 全 面 的 分 析 。 由 于 Android 的 消 恩 机 制 实际 上 
束 是 Handler 的 运行 机 制 ， 因 此 本 市 主要 围绕 着 Handler 的 工作 过 程 来 分 
析 Android 的 消息 机 制 ， 主 要 包括 Handler、MessageQueue 和 Looper。 
同时 为 了 更 好 地 理解 Looper 的 工作 原理 ， 本 市 还 会 介绍 ThreadLocal， 
通过 本 市 的 介绍 可 以 让 读者 对 Android 的 消 恩 机制 有 一 个 深入 的 理解 。 


10.2.1 ”ThreadLocal 的 工作 原理 


ThreadLocal 是 一 个 线程 内 部 的 数据 存储 类 ， 通 过 它 可 以 在 指定 的 
线程 中 存储 数据 ， 数 据 存 储 以 后 ， 只 有 在 指定 线程 中 可 以 获取 到 存储 


的 数据 ， 对 于 其 他 线程 来 说 则 无 法 获取 到 数据 。 在 日 常 开 发 中 用 到 
ThreadLocal 的 地 方 较 少 ， 但 是 在 某 些 特殊 的 场景 下 ， 通 过 ThreadLocal 
可 以 轻松 地 实现 一 些 看 起 来 很 复杂 的 功能 ， 这 一 点 在 Android 的 源码 中 
也 有 所 体现 ， 比 如 Looper、ActivityThread 以 及 AMS 中 都 用 到 了 
ThreadLocal。 上 有 具体 到 ThreadLocal 的 使 用 场景 ， 这 个 不 好 统一 来 描述， 
一 般 来 说 ， 当 某 些 数 据 是 以 线程 为 作用 域 并 且 不 同 线程 具有 不 同 的 数 
据 副 本 的 时 候 ， 束 可 以 考虑 采用 ThreadLocal。 比 如 对 于 Handler 来 说 ， 
它 需 要 获取 当前 线程 的 Looper， 很 显然 Looper 的 作用 域 束 是 线程 并 且 
不 同 线 程 具 有 不 同 的 Looper， 这 个 时 候 通 过 ThreadLocal 束 可 以 轻松 实 
现 Looper 在 线程 中 的 存 取 。 如 果 不 采 用 ThreadLocal， 那 么 系统 驶 必须 
提供 一 个 全 局 的 哈 希 表 供 Handler 查 找 指 定 线 程 的 Looper , PRA 
必须 提供 一 个 类 似 于 LooperManager 的 类 了 ， 但 是 系统 并 没有 这 么 做 而 
是 选择 了 ThreadLocal， 这 束 是 ThreadLocal 的 好 处 。 


ThreadLocal 另 一 个 使 用 场景 是 复杂 逻辑 下 的 对 象 传递 ， 比 如 监听 
独 的 传递 ， 有 些 时 候 一 个 线程 中 的 任务 过 于 复杂 ， 这 可 能 表现 为 钞 数 
调用 栈 比 较 深 以 及 代码 入 口 的 多 样 性 ， 在 这 种 情况 下 ， 我 们 又 需要 监 
听 需 能够 贯穿 整个 线程 的 执行 过 程 ， 这 个 时 候 可 以 怎么 做 昵 ? 其 实 这 
时 就 可 以 采用 ThreadLocal， 采 用 ThreadLocal 可 以 让 监听 器 作为 线程 内 
的 全 局 对 象 而 存在 ， 在 线程 内 部 只 要 通过 get 方 法 就 可 以 获取 到 监听 
絮 。 如 果 不 末 用 ThreadLocal， 那 么 我 们 能 想到 的 可 能 是 如 下 两 种 方 
YE: 第 一 种 方法 是 将 监听 喜 通 过 参数 的 形式 在 函数 调用 栈 中 进行 传 
递 ， 第 二 种 方法 就 是 将 监听 器 作为 静态 变量 供 线 程 访 问 。 上 述 这 两 种 
方法 都 是 有 局 限 性 的 。 第 一 种 方法 的 问题 是 当 函 数 调用 栈 很 深 的 时 
候 ， 通 过 函数 参数 来 传递 监听 吉 对 象 这 几乎 是 不 可 接受 的 ， 这 会 让 程 
序 的 设计 看 起 来 很 糟 灯 。 第 二 种 方法 是 可 以 接受 的 ， 但 是 这 种 状态 是 
不 具有 可 扩充 性 的 ， 比 如 同时 有 两 个 线程 在 执行 ， 那 么 就 需要 提供 两 


个 静态 的 监听 器 对 象 ， 如 果 有 10 个 线程 在 并 发 执行 呢 ? 提供 10 个 静态 
的 监听 器 对 象 ? 这 显然 是 不 可 思议 的 ， 而 采用 ThreadLocal， 每 个 监听 
句 对 象 都 在 自己 的 线程 内 部 存储 ， 根 本 就 不 会 有 方法 2 的 这 种 问题 。 


介绍 了 那么 多 ThreadLocal 的 知识 ， 可 能 还 是 有 点 抽象 ， 下 面 通 
实际 的 例子 来 演示 ThreadLocal 的 真正 含义 。 SR 
对 象 ， 这 里 选择 Boolean 类 型 的 ， 如 下 所 示 。 


private ThreadLocal<Boolean> mBooleanThreadLocal = new 


ThreadLocal<Boolean>(); 


然后 分 别 在 主线 程 、 子 线程 1 和 子 线程 2 中 设置 和 访问 它 的 值 ， 代 
码 如 下 所 示 。 


mBooleanThreadLocal. set(true); 
Log.d(TAG, "[Thread#main |mBooleanThreadLocal=" 十 
mBooleanThreadLocal.get()); 
new Thread("Thread#1") { 
@Override 
public void run() { 
mBooleanThreadLocal.set(false); 
Log.d(TAG, "[Thread+1]mBooleanThreadLocal=" + 
mBooleanThreadLocal.get()); 
}; 
}.start(); 
new Thread("Thread#2") { 
@Override 


public void run() { 


Log.d(TAG, "[Thread+2]mBooleanThreadLocal=" + 
mBooleanThreadLocal.get()); 
}; 
}.start(); 


在 上 面 的 代码 中 ， 在 主线 程 中 设置 mBooleanThreadLocal 的 值 为 
true， 在 子 线程 1 中 设置 mBooleanThreadLocal 的 值 为 false， 在 子 线程 2 
中 不 设置 mBooleanThreadLocal 的 值 。 然 后 分 别 在 3 个 线程 中 通过 get 方 
法 获取 mBooleanThreadLocal 的 值 ， 根 据 前 面 对 ThreadLocal 的 描述 ， 这 
个 时 候 ， 主 线程 中 应 该 是 true， 子 线程 1 中 应 该 是 false， 而 子 线程 2 中 由 
于 没有 设置 值 ， 所 以 应 该 是 null。 安 装 并 运行 程序 ， 日 志 如 下 所 示 。 


D/TestActivity(8676): [Thread#main]mBooleanThreadLocal=true 
D/TestActivity(8676): [Thread#1]mBooleanThreadLocal=false 


D/TestActivity(8676): [Thread#2]mBooleanThreadLocal=null 


从 上 面 日 志 可 以 看 出 ， 虽 然 在 不 同 线程 中 访问 的 是 同一 
nes 但 是 它们 通过 ThreadLocal 获 取 到 的 值 却 是 不 e 
的 ， 这 天 是 ThreadLocal 的 奇妙 之 处 。 结 合 这 个 例子 然后 再 看 一 过 前 面 
对 ThreadLocal 的 两 个 使 用 场景 的 理论 分 析 ， 我 们 应 该 瓯 能 比较 好 地 理 
解 ThreadLocal 的 使 用 方法 了 。ThreadLocal 之 所 以 有 这 么 奇妙 的 效果 ， 
是 因为 不 同 线程 访问 同一 个 ThreadLocal 的 get 方 法 ，ThreadLocal 内 部 会 
从 各 目的 线程 中 取出 一 个 数组 ， 然 后 再 从 数组 中 根据 当前 ThreadLocal 
的 索引 去 查找 出 对 应 的 value 值 。 很 显然 ， 不 同 线程 中 的 数组 是 不 同 
的 ， 这 焉 是 为 什么 通过 ThreadLocal 可 以 在 不 同 的 线程 中 维护 一 套数 据 
的 副本 并 且 彼 此 互 不 干扰 。 


对 ThreadLocal 的 使 用 方法 和 工作 过 程 做 了 介绍 后 ， 下 面 分 析 
ThreadLocal 的 内 部 实现 ，ThreadLocal 是 一 个 泛 型 类 ， 它 的 定义 为 
public class ThreadLocal<T> ， 只 要 弄 请 楚 ThreadLocal 的 get 和 set 方 法 束 
可 以 明白 它 的 工作 原理 。 


首先 看 ThreadLocal 的 set 方 法 ， 如 下 所 示 。 


public void set(T value) { 
Thread currentThread = Thread.currentThread(); 
Values values = values(currentThread); 
if (values == null) { 
values = initializeValues(currentThread) ; 
} 
values.put(this, value); 


i 


在 上 面 的 set 方 法 中 ， 首 先 会 通过 values 方 法 来 获取 当前 线程 中 的 
ThreadLocal 数 据 ， 如 何 获取 呢 ? 其 实 获取 的 方式 也 是 很 简单 的 ， 在 
Thread 类 的 内 部 有 一 个 成 员 专 门 用 于 存储 线程 的 ThreadLocal 的 数据 : 
ThreadLocal.Values localValues, 此 获取 当前 线程 的 ThreadLocal 数 据 
束 变 得 异常 简单 了 。 如果]localValues 的 值 为 null， 那 么 就 需要 对 其 进行 
初始 化 ， 初 始 化 后 再 将 ThreadLocal 的 值 进 行 存储 。 下 面 看 一 下 
ThreadLocal 的 值 到 底 是 如 何在 localValues 中 进行 存储 的 。 在 localValues 
内 部 有 一 个 数组 : private Object[] table ，ThreadLocal 的 值 就 存在 在 这 
个 table 数 组 中 。 下 面 看 一 下 localValues 是 如 何 使 用 put 方 法 将 
ThreadLocal 的 值 存储 到 table 数 组 中 的 ， 如 下 所 示 。 


return; 
} 
// Remember first tombstone. 
if (firstTombstone == -1 && k == TOMBSTONE) { 


firstTombstone = index; 


} 


上 面 的 代码 实现 了 数据 的 存储 过 程 ， 这 里 不 去 分 析 它 的 具体 算 
法 ， 但 是 我 们 可 以 得 出 一 个 存储 规划 ， 那 惑 是 ThreadLocal 的 值 在 table 
数组 中 的 存储 位 置 总 是 为 ThreadLocal 的 reference 字 段 所 标识 的 对 象 的 
下 一 个 位 置 ， 比 如 ThreadLocal 的 reference 对 象 在 table 数 组 中 的 索引 为 
index， 那 么 ThreadLocal 的 值 在 table 数 组 中 的 索引 就是 index+1。 最终 
ThreadLocal 的 值 将 会 被 存储 在 table 数 组 中 : table[index + 1] = value ° 


上 面 分 析 了 ThreadLocal 的 set 方 法 ， 这 里 分 析 它 的 get 方 法 ， 如 下 所 
ZR e 


public T get() { 
// Optimized for the fast path. 
Thread currentThread = Thread.currentThread(); 
Values values = values(currentThread); 
if (values != null) { 
Object[] table = values.table; 
int index = hash & values .mask; 
if (this.reference == table[index]) { 


return (T) table[index + 1]; 


可 以 发 现 ，ThreadLocal 的 get 方 法 的 逻辑 也 比较 清晰 ， 它 同样 是 取 
出 当前 线程 的 local-Values 对 象 ， 如 果 这 个 对 象 为 null 那 么 就 返回 初始 
值 ， 初 始 值 由 ThreadLocal 的 initialvalue 方 法 来 朱 述 ， 默 认 情 况 下 为 
null， 当 然 也 可 以 重 写 这 个 方法 ， 它 的 默认 实现 如 下 所 示 。 


Ul local Values Xf 4 ANA null, HS we AL tt E AY table Zir tH FF FR H 
ThreadLocal 的 reference 对 和 象 在 table 数 组 中 的 位 置 ， 然 后 table 数 组 中 的 
下 一 个 位 置 所 存储 的 数据 就 是 ThreadLocal 的 值 。 


从 ThreadLocal 的 set 和 get 方 法 可 以 看 出 ， 它 们 所 操作 的 对 象 都 是 当 
前 线程 的 localValues 对 象 的 table 数 组 ， 因 此 在 不 同 线程 中 访问 同一 
ThreadLocal 的 set 和 get 方 法 ， 它 们 对 ThreadLocal 所 做 的 读 / 写 操作 仪 限 
于 各 自 线 程 的 内 部 ， 这 就 是 为 什么 ThreadLocal 可 以 在 多 个 线程 中 互 不 
干扰 地 存储 和 修改 数据 ， 理 解 ThreadLocal 的 实现 方式 有 助 于 理解 
Looper 的 工作 原理 。 


10.2.2 ”消息 队列 的 工作 原理 


消息 队列 在 Android 中 指 的 是 MessageQueue ，MessageQueue 主 要 
包含 两 个 操作 : 插入 和 读 取 。 读 取 操 作 本 号 会 伴随 着 删除 操作 ， 插 入 
和 读 取 对 应 的 方法 分 别 为 enqueueMessage 和 next， 其 中 enqueueMessage 
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取出 一 条 消息 并 将 其 从 消息 队列 中 移 除 。 尽管 MessageQueue 叫 消息 队 
列 ， 但 是 它 的 内 部 实现 并 不 是 用 的 队列 ， 实 际 上 它 是 通过 一 个 单 链表 
的 数据 结构 来 维护 消息 列表 ， 单 链表 在 插入 和 删除 上 比较 有 优势 。 下 
面 主 要 看 一 下 它 的 enqueueMessage 和 next 方 法 的 实现 ，enqueueMessage 
的 源码 如 下 所 示 。 


boolean enqueueMessage(Message msg,long when) { 


synchronized (this) { 


msg.markInUse(); 


msg.when = when; 


Message p = mMessages; 


从 enqueueMessage 的 实现 来 看 ， 它 的 主要 操作 其 实 束 是 单 链表 的 
插入 操作 ， 这 里 束 不 再 过 多 解释 了 ， 下 面 看 一 下 next 方 法 的 实现 ，next 
的 主要 逻辑 如 下 所 示 。 


可 以 发 现 next 方 法 是 一 个 无 限 循环 的 方法 ， 如 果 消 轧 队 列 中 没有 
消息 ， 那 么 next 方 法 会 一 直 阻 塞 在 这 里 。 当 有 新 消息 到 来 时 ，next 方 法 
会 返回 这 条 消息 并 将 其 从 单 链表 中 移 除 。 


10.2.3 Looper TRA 


10.2.20 FB T AAIE, AT Looperh A 
体 实 现 。Looper 在 Android 的 消息 机 制 中 扮演 着 消息 循环 的 角色 ， 有 具体 
来 说 束 是 它 会 不 停 地 从 MessageQueue 中 查看 是 否 有 新 消息 ， 如 果 有 新 
消息 整 会 立刻 处 理 ， 否 则 束 一 直 阻 塞 在 那里 。 首 先 看 一 下 它 的 构造 方 
法 ， 在 构造 方法 中 它 会 创建 一 个 MessageQueue 即 消息 队列 ， 然 后 将 当 
前 线程 的 对 象 保 存 起 来 ， 如 下 所 示 。 


private Looper(boolean quitAllowed) { 
mQueue = new MessageQueue(quitAllowed); 


mThread = Thread.currentThread(); 


} 


我 们 知道 ，Handler 的 工作 需要 Looper， 没 有 Looper 的 线程 就 会 报 
错 ， 那 么 如 何 为 一 个 线程 创建 Looper 昵 ? 其 实 很 简单 ， 通 过 
Looper.prepare() È} 可 为 当前 线程 创建 一 个 Looper ， 接 着 通过 
Looperloop(0 来 开局 消息 循环 ， 如 下 所 示 。 


new Thread("Thread#2") { 
@Override 
public void run() { 
Looper .prepare(); 
Handler handler = new Handler(); 
Looper.loop(); 
ti 
}.start(); 


Looper 除 了 prepare 方 法 外 ， 还 提供 了 prepareMainLooper 方 法 ， 这 
SA BEREA EZRA te ActivityThread l Looper AA, HA 
质 也 是 通过 prepare 方 法 来 实现 的 。 由 于 主线 程 的 Looper 比 较 特 殊 ， 所 
以 Looper 提 供 了 一 个 getMainLooper 方 法 ， 通 过 它 可 以 在 任何 地 方 获取 
到 主线 程 的 Looper。Looper 也 是 可 以 退出 的 ，Looper 提 供 了 guit 和 
quitSafely 来 退出 一 个 Looper， 二 者 的 区 别 是 : quit 会 直接 退出 Looper， 
nn... 然后 把 消 Be A 
理 完毕 后 才 安 全 地 退出 。Looper 退 出 后 ， 通 过 Handler 发 送 的 消息 
败 ， 这 个 时 候 Handler 的 send 方 法 会 返回 false。 在 子 线程 中 ， RES 
为 其 创建 了 Looper， 那 么 在 所 有 的 事情 完成 以 后 应 该 调用 quit 方 法 来 终 
止 消息 循环 ， A a a 而 如 采 退 出 
Looper 以 后 ， 这 个 线程 陇 会 立刻 终止 ， 因 此 建议 不 需要 的 时 候 终止 


Looper ° 


Looper 最 重要 的 一 个 方法 是 loop 方 法 ， 只 有 调用 了 loop 后 ， 消 息 循 
环 系 统 才 会 真正 地 起 作用 ， 它 的 实现 如 下 所 示 。 


/** 
* Run the message queue in this thread. Be sure to call 
* {@link #quit()} to end the loop. 
ae 
public static void loop() { 
final Looper me = myLooper(); 
if (me == null) { 
throw new RuntimeException("No Looper; 


Looper.prepare() wasn't called on this thread."); 


5 


Looper 的 loop 方 法 的 工作 过 程 也 比较 好 理解 ，loop 方 法 是 一 个 死 循 
环 ， 唯 一 跳出 循环 的 方式 是 MessageQueue 的 next 方 法 返回 了 null。 当 
Looper 的 quit 方 法 被 调用 时 ，Looper 就 会 调用 MessageQueue 的 quit 或 者 
quitSafely 方 法 来 通知 消息 队列 退出 ， 当 消息 队列 被 标记 为 退出 状态 
上 时， 它 的 next 方 法 就 会 返回 null。 也 就 是 说 ，Looper 必 须 退 出 ， 否 则 


loop 方 法 就 会 无 限 循环 下 去 。1oop 方 法 会 调用 MessageQueue 的 next 方 法 
来 获取 新 消 上 息 ， 而 next 是 一 个 阻塞 操作 ， 当 没有 消 轧 时 ，next 方 法 会 一 
直 阻 塞 在 那里 ， 这 也 导致 loop 方 法 一 直 阻 塞 在 那里 。 如 果 
MessageQueue 的 next 方 法 返回 了 新 消息 ，Looper 束 会 处 理 这 条 消息 : 
msg.target.dispatchMessage(msg)， 这 里 的 msg.target 是 发 送 这 条 消息 的 
Handler 对 象 ， 这 样 Handler 发 送 的 消息 最 终 又 交 给 它 的 dispatchMessage 
方法 来 处 理 了 。 但 是 这 里 不 同 的 是 ，Handler 的 dispatchMessage 方 法 是 
在 创建 Handler 时 所 使 用 的 Looper 中 执行 的 ， 这 样 就 成 功 地 将 代码 逻辑 
切换 到 指定 的 线程 中 去 执行 了 。 


10.2.4 Handler 的 工作 原理 


Handler 的 工作 主要 包含 消息 的 发 送 和 接收 过 程 。 消 息 的 发 送 可 以 
通过 post 的 一 系列 方法 以 及 send 的 一 系列 方法 来 实现 ，post 的 一 系列 方 
法 最 终 是 通过 send 的 一 系列 方法 来 实现 的 。 发 送 一 条 消息 的 典型 过 程 
如 下 所 示 。 


public final boolean sendMessage(Message msg) 
return sendMessageDelayed(msg, 0); 
} 
public final boolean sendMessageDelayed(Message msg, long 
delayMillis) 
i 
if (delayMillis < 0) { 
delayMillis = 0; 


可 以 发 现 ，Handler 发 送 消息 的 过 程 仅 仅 是 癌 消 息 队 列 中 插入 了 一 
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Looper 收 到 消息 后 歼 开 始 处 理 了 ， 最 终 消 息 由 Looper 交 由 Handler 处 
理 ， 即 Handler 的 dispatchMessage 方 法 会 补 调 用 ， 这 时 Handler 就 进入 了 
处 理 消息 的 阶段 。dispatchMessage 的 实现 如 下 所 示 。 


public void dispatchMessage(Message msg) { 
if (msg.callback != null) { 
handleCallback(msg); 
) else { 
if (mCallback != null) { 
if (mCallback.handleMessage(msg)) { 


return; 


i 


handleMessage(msg); 


} 
Handler 处 理 消息 的 过 程 如 下 : 


首先 ， 检 查 Message 的 callback 是 否 为 nul ， 不 为 null 就 通过 
handleCallback 来 处 理 消 息 。Message 的 callback 是 一 个 Runnable 对 象 ， 
实际 上 残 是 Handler 的 post 方 法 所 传递 的 Runnable 参 数 。handleCallback 
的 逻辑 也 是 很 简单 ， 如 下 所 示 。 


private static void handleCallback(Message message) { 


message.callback.run(); 


} 


其 次 ， 检 查 mCallback 是 否 为 null， 不 为 null 就 调用 mcCallback 的 
handleMessage 方 法 来 处 理 消 fa, e Callbacke: NHO, EYRE UIP: 


/** 
* Callback interface you can use when instantiating a 

Handler to avoid 

* having to implement your own subclass of Handler. 

* @param msg A {@link android.os.Message Message} object 

* @return True if no further handling is desired 

ae 

public interface Callback { 


public boolean handleMessage(Message msg); 


Y Callback FJ 以 采用 如 下 方式 来 创建 Handler 对 象 : Handler 
handler = new Handler(callback) ° 那么 Callback 的 意义 是 什么 呢 ? 源码 
里 面 的 注释 已 经 做 了 说 明 : 可 以 用 来 创建 一 个 Handler 的 实例 但 并 不 需 
要 派生 Handler 的 子 类 。 在 日 常 开 发 中 ， 创 建 Handler 最 常见 的 方式 束 是 
la 生 一 个 Handler 的 子 类 并 重 写 其 handleMessage 方 法 来 处 理 具体 的 消 

， 而 Callback 给 我 们 提供 了 另外 一 种 使 用 Handler 的 方式 ， 当 我 们 不 

想 派 生子 类 时 就 可 以 通过 Callback 来 实现 。 


最 后 ， 调 用 Handler 的 handleMessage 方 法 来 处 理 消 息 。Handler 处 
理 消 息 的 过 程 可 以 归纳 为 一 个 流程 图 ， 如 图 10-2 所 示 。 
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Y < msg. callback != sl 
[ N 


handleCallback AR jæ > 


Br ‘mCallba ck.handle Message(msg) ——— 
=== == true te zz 


图 10-2 ”Handler 消 息 处 理 流程 医 


Handler 还 有 一 个 特殊 的 构造 方法 ， 那 束 古 通过 一 个 特定 的 Looper 
来 构造 Handler， 它 的 实现 如 下 所 示 。 通 过 这 个 构造 方法 可 以 实现 一 些 
特殊 的 功能 。 


public Handler(Looper looper) { 


this(looper,null, false); 


下 面 看 一 下 Handler 的 一 个 默认 构造 方法 public Handler), 3X 4% 
造 方法 会 调用 下 面 的 构造 方法 。 很 明显 ， 如 果 当 前 线程 没有 Looper 的 
i , ME HH “Can't create handler inside thread that has not called 
Looperprepare0” 这 个 异常 ， 这 也 解释 了 在 没有 Looper 的 子 线程 中 创建 
Handler 会 引发 程序 异常 的 原因 。 


public Handler(Callback callback,boolean async) { 


mLooper = Looper.myLooper(); 
if (mLooper == null) { 
throw new RuntimeException( 
"Can't create handler inside thread 
that has not called Looper.prepare()"); 
} 
mQueue = mLooper .mQueue; 
mCallback = callback; 


mAsynchronous = async; 


10.3 ”主线 程 的 消息 循环 


Android 的 主线 程 就 是 ActivityThread， 主 线程 的 入 口 方法 为 main， 
在 main 方 法 中 系统 会 通过 Looper.prepareMainLooper() 来 创建 主线 程 的 


Looper 以 及 MessageQueue， 并 通过 Looperloop0) 来 开启 主线 程 的 消息 循 
环 ， 这 个 过 程 如 下 所 示 。 


主线 程 的 消息 循环 开始 了 以 后 ，ActivityThread 还 需要 一 个 Handler 
来 和 消息 队列 进行 交互 ， 这 个 Handler 就 是 ActivityThread.H， 它 内 部 定 
义 了 一 组 消息 类 型 ， 主 要 包含 了 四 大 组 件 的 局 动 和 停止 等 过 程 ， 如 下 
PTA > 


ActivityThread i 34 ApplicationThread 和 AMS 进行 进程 间 通 信 ， 
AMS 以 进程 间 通 信 的 方式 完成 ActivityThread 的 请 求 后 会 回调 
ApplicationThread 中 的 Binder 方 法 ， 然 后 ApplicationThread 会 同 阳 发 送 
BR, HU #98 A Ja E # ApplicationThread 中 的 逻辑 切换 到 
ActivityThread F EHT, EDREAL ARERAZEAS, MAME 
线程 的 消息 人 循环 模型 。 


第 11 章 Android 的 线程 和 线程 池 


本 章 的 主题 是 Android 中 的 线程 和 线程 池 。 线 程 在 Android 中 是 一 
个 很 重要 的 概念 ， 从 用 途上 来 说 ， 线 程 分 为 主线 程 和 子 线 程 ， 主 线程 
主要 处 理 和 界面 相关 的 事情 ， 而 子 线程 则 往往 用 于 执行 耗 时 操作 。 由 
于 Android 的 特性 ， 如 有 果 在 主线 程 中 执行 耗 时 操作 那么 惑 会 导致 程序 无 
法 及 时 地 啊 应 ， 因 此 耗 时 操作 必须 放 在 子 线程 中 去 执行 。 除 了 Thread 
本 号 以 外 ， 在 Android 中 可 以 扮演 线程 角色 的 还 有 很 多 ， 比 如 
AsyncTask 和 JIntentService， 同 时 HandlerThread 也 是 一 种 特殊 的 线程 。 
尽管 AsyncTask、IntentService 以 及 HandlerThread 的 表现 形式 都 有 别 于 
传统 的 线程 ， 但 是 它们 的 本 质 仍 然 是 传统 的 线程 。 对 于 AsyncTask 来 
说 ， 它 的 底层 用 到 了 线程 池 ， 对 于 IntentService 和 HandlerThread 来 说 ， 
它们 的 底层 则 直接 使 用 了 线程 。 


不 同形 式 的 线程 虽然 都 是 线程 ， 但 是 它们 仍然 具有 不 同 的 特性 和 
使 用 场景 。AsyncTask 封 装 了 线程 池 和 Handler， 它 主要 是 为 了 方便 开 
发 者 在 子 线程 中 更 新 UI。HandlerThread 是 一 种 具有 消息 循环 的 线程 ， 
在 它 的 内 部 可 以 使 用 Handler。IntentService 是 一 个 服务 ， 系 统 对 其 进 
行 了 封装 使 其 可 以 更 方便 地 执行 后 台 任 务 ，IntentService 内 部 采用 
HandlerThread 来 执行 任务 ， 当 任务 执行 完 昔 后 IntentService 会 和 目 动 退 
出 。 从 任务 执行 的 角度 来 看 ，IntentService 的 作用 很 像 一 个 后 台 线 程 ， 
但 是 IntentService 是 一 种 服务 ， 它 不 容易 被 系 统 杀 死 从 而 可 以 尽量 你 证 
任务 的 执行 ， 而 如 果 是 一 个 后 台 线 程 ， 由 于 这 个 时 候 进 程 中 没有 活动 
的 四 大 组 件 ， 那 么 这 个 进程 的 优先 级 束 会 非常 低 ， 会 很 容易 被 系统 杀 
死 ， 这 就 是 IntentService 的 优点 。 


在 操作 系统 中 ， 线 程 是 操作 系统 调度 的 最 小 单元 ， 同 时 线程 又 是 
一 种 受 限 的 系统 资产， 即 线程 不 可 能 无 限制 地 产生 ， 并 且 线 程 的 创建 
和 销毁 都 会 有 相应 的 开销 。 当 系统 中 存在 大 量 的 线程 时 ， 系 统 会 通过 
时 间 片 轮转 的 方式 调度 每 个 线程 ， 因 此 线程 不 可 能 做 到 绝对 的 并 行 ， 
除非 线程 数量 小 于 等 于 CPU 的 核心 数 ， 一 般 来 说 这 是 不 可 能 的 。 试 想 
一 下 ， 如 采 在 一 个 进程 中 频繁 地 创建 和 销毁 线程 ， 这 显然 不 是 高 效 的 
做 法 。 正 确 的 做 法 是 采用 线程 池 ， 一 个 线程 池 中 会 缓存 一 定数 量 的 线 
程 ， 通 过 线程 池 残 可 以 避免 因为 频 和 党 创建 和 销毁 线程 所 佛 来 的 系统 
销 。Android 中 的 线程 池 来 源 于 Java， 主 要 是 通过 Executor 来 派生 特定 
类 型 的 线程 池 ， 不 同 种 类 的 线程 池 又 具有 各 上 自 的 特性 ， 详 细 内 容 会 在 
11.3 节 中 进行 介绍 。 


11.1 主线 程 和 子 线程 


主线 程 是 指 进程 所 拥有 的 线程 ， 在 Java 中 默认 情况 下 一 个 进程 只 
有 一 个 线程 ， 这 个 线程 就 是 主线 程 。 主 线程 主要 处 理 界面 交互 相关 的 
逻辑 ， 因 为 用 户 随时 会 和 界面 发 生 交 互 ， 因 此 主线 程 在 任何 时 候 都 必 
须 有 较 高 的 啊 应 速度 ， 否 则 整 会 产生 一 种 界面 卡 顿 的 感觉 。 为 了 保持 
较 高 的 啊 应 速度 ， 这 束 要 求 主 线程 中 不 能 执行 耗 时 的 任务 ， 这 个 时 候 
子 线程 就 派 上 用 场 了 。 了 线程 也 叫 工作 线程 ， 除 了 主线 程 以 外 的 线程 
都 是 子 线程 。 


Android 沿 用 了 Java 的 线程 模型 ， 其 中 的 线程 也 分 为 主线 程 和 子 线 
程 ， 其 中 主线 程 也 叫 UI 线 程 。 主 线程 的 作用 是 运行 四 大 组 件 以 及 处 理 
它们 和 用 户 的 交互 ， 而 子 线程 的 作用 则 是 执行 耗 时 任务 ， 比 如 网 络 请 
求 、IO 操 作 等 。 从 Android 3.0 开 始 系统 要 求 网 络 访问 必须 在 子 线程 中 


íT, RU 2S AS AMM IE H NetworkOnMainThreadException 
这 个 异常 ， 这 样 做 是 为 了 避免 主线 程 由 于 被 耗 时 操作 所 阻塞 从 而 出 现 
ANR 现 象 。 


11.2 ” Android 中 的 线程 形态 


本 市 将 对 Android 中 的 线程 形态 做 一 个 全 面 的 介绍 ， 除 了 传统 的 
Thread LAY}, 144% AsyncTask > HandlerThread LA X IntentService, X 
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用 上 也 各 有 优 缺 点 。 为 了 简化 在 子 线程 中 访问 UI 的 过 程 ， 系 统 提 供 了 
AsyncTask, ，AsyncTask 经 过 儿 次 人 和 修改， 导致 了 对 于 不 同 的 API 版 本 
AsyncTask 具 有 不 同 的 表现 ， 尤 其 是 多 任务 的 并 发 执行 上 。 由 于 这 个 原 
因 ， 很 多 开发 者 对 AsyncTask 的 使 用 上 存在 误区 ， 本 和 将 详细 介绍 使 用 
AsyncTask 时 的 注意 事项 ， 并 从 源码 的 角度 来 分 析 AsyncTask 的 执行 过 
程 。 


11.2.1 AsyncTask 


AsyncTask 是 一 种 轻 量 级 的 异步 任务 类 ， 它 可 以 在 线程 池 中 执行 后 
台 任 务 ， 然 后 把 执行 的 进度 和 最 终结 果 传 递 给 主线 程 并 在 主线 程 中 更 
新 UI。 从 实现 上 来 说 ，AsyncTask 封 装 了 Thread 和 Handler ， 通 过 
AsyncTask 可 以 更 加 方便 地 执行 后 台 任务 以 及 在 主线 程 中 访问 UI， 但 是 
AsyncTask 并 不 适合 进行 特别 耗 时 的 后 台 任 务 ， 对 于 特别 耗 时 的 任务 来 
说 ， 建 议 使 用 线程 池 。 


AsyncTask 是 一 个 抽象 的 泛 型 类 ， 它 提供 了 Params、Progress 和 
Result 这 三 个 泛 型 参数 ， 其 中 Params 表 示人 参数 的 类 型 ，Progress 表 示 后 
台 任 务 的 执行 进度 的 类 型 ， 而 Result 则 表示 后 台 任 务 的 返回 结果 的 类 
型 ， 如 有 果 AsyncTask 确 实 不 需要 传递 具体 的 参数 ， 那 么 这 三 个 沁 型 参数 
可 以 用 Void 来 代替 。AsyncTask 这 个 类 的 声明 如 下 所 示 。 


public abstract class AsyncTask<Params, Progress, Result> > 
AsyncTask 提 供 了 4 个 核心 方法 ， 它 们 的 含义 如 下 所 示 。 


(1) onPreExecute()， 在 主线 程 中 执行 ， 在 异步 任务 执行 之 前 ， 
此 方法 会 被 调用 ， 一 般 可 以 用 于 做 一 些 准 备 工 作 。 


(2) doInBackground(Params...params)， 在 线程 池 中 执行 ， 此 方法 
用 于 执行 异步 任务 ，params 参 数 表示 异步 任务 的 输入 参数 。 在 此 方法 
中 可 以 通过 publishProgress 方 法 来 更 新 任务 的 进度 ，publishProgress 方 
法 会 调用 onProgressUpdate 方 法 。 另 外 此 方法 需要 返回 计算 结果 给 
onPostExecute 方 法 。 


(3) onProgressUpdate(Progress...values)， 在 主线 程 中 执行 ， 当 后 
台 任 务 的 执行 进度 发 生 改 变 时 此 方法 会 被 调用 。 


(4) onPostExecute(Result result)， 在 主线 程 中 执行 ， 在 异步 任务 
执行 之 后 ， 此 方法 会 被 调用 ， 其 中 result 参 数 是 后 台 任 务 的 返回 值 ， 即 
doInBackgroundHJi EÉ. ° 


上 面 这 几 个 方法 ，onPreExecute 先 执行 ， 接 着 是 doImnBackground 
最 后 才 是 onPostExecute。 除了 上 上述 四 个 方法 以 外 ，AsyncTask 还 提供 了 
onCancelled() 方 法 ， 它 同样 在 主线 程 中 执行 ， 当 异步 任务 被 取消 时 ， 


onCancelled0) 方 法 会 被 调用 ， 这 个 时 候 onPostExecute 则 不 会 被 调用 。 
下 面 提供 一 个 典型 的 示例 ， 如 下 所 示 。 


在 上 面 的 代码 中 ， 实 现 了 一 个 具体 的 AsyncTask 类 ， 这 个 类 主要 用 
于 模拟 文件 的 下 载 过 程 ， 它 的 输入 参数 类 型 为 URL， 后 台 任 务 的 进程 
参数 为 Integer， 而 后 台 任 务 的 返回 结果 为 Long 类 型 。 注 意 到 
doInBackground 和 onProgressUpdate 方 法 它们 的 参数 中 均 包 含 ... 的 字 
样 ， 在 Java 中 ... 表 示 参 数 的 数量 不 定 ， 它 是 一 种 数组 型 参数 ，... 的 概 
念 和 C 语 言 中 的 .是 一 致 的 。 当 要 执行 上 述 下 载 任务 时 ， 可 以 通过 如 
TADA 


new DownloadFilesTask().execute(url1,url2,ur13); 


在 DownloadFilesTask 中 ，doInBackground 用 来 执行 具体 的 下 载 任 
务 并 通过 publishProgress 方 法 来 更 新 下 载 的 进度 ， 同 时 还 要 判断 下 载 任 
务 是 否 被 外 界 取 消 了 。 当 下 载 任务 完成 后 ，doInBackground 会 返回 结 
果 ， 即 下 载 的 总 字 节 数 。 需 要 注意 的 是 ，doImBackground 是 在 线程 池 
中 执行 的 。onProgressUpdate 用 于 更 新 界面 中 下 载 的 进度 ， 它 运行 在 主 
线程 ， 当 publishProgress 被 调用 时 ， 此 方法 束 会 被 调用 。 当 下 载 任务 完 
成 后 ，onPostExecute 方 法 吏 会 被 调用 ， 它 也 是 运行 在 主线 程 中 ， 这 个 
时 候 我 们 就 可 以 在 界面 上 做 出 一 些 提 示 ， 比 如 弹出 一 个 对 话 框 告知 用 
户 下 载 已 经 完成 。 


AsyncTask 在 具体 的 使 用 过 程 中 也 是 有 一 些 条 件 限制 的 ， 主 要 有 如 
Th 


(1) AsyncTask 的 类 必须 在 主线 程 中 加 载 ， 这 就 意味 着 第 一 次 访 
问 AsyncTask 必 须发 生 在 主线 程 ， 当 然 这 个 过 程 在 Android 4.1 及 以 上 版 
本 中 已 经 被 系统 目 动 完 成 。 在 Android 5.0 的 源码 中 ， 可 以 查看 
ActivityThread 的 main 方 法 ， 它 会 调用 AsyncTask 的 init 方 法 ， 这 就 满足 
了 AsyncTask 的 类 必须 在 主线 程 中 进行 加 载 这 个 条 件 了 。 至 于 为 什么 必 


须要 满足 这 个 条 件 ， 在 11.2.2 市 中 会 结合 AsyncTask 的 源码 再 次 分 析 这 


个 问题 。 
(2) AsyncTask 的 对 象 必须 在 主线 程 中 创建 。 


(3) execute 方 法 必须 在 UI 线程 调用 。 


(4) 不 要 在 程序 中 直接 调用 onPreExecute()、onPostExecute ` 
doInBackground 和 onProgressUpdate 方 法 。 


(5) 一 个 AsyncTask 对 象 只 能 执行 一 次 ， 即 只 能 调用 一 次 execute 
方法 ， 否 则 会 报 运行 时 异常 。 


(6) 在 Android 1.6 之 前 ，AsyncTask 是 串 行 执行 任务 的 ，Android 
1.6 的 时 候 AsyncTask 开 始 采用 线程 池 里 处 理 并 行 任务 ， 但 是 从 Android 
3.0 开 始 ， 为 了 人 避免 AsyncTask 所 市 来 的 并 发 错误 ，AsyncTask 又 采用 一 
个 线程 来 串 行 执行 任务 。 尽 管 如 此 ， 在 Android 3.0 以 及 后 续 的 版 本 
中 ， 我 们 仍然 可 以 通过 AsyncTask 的 executeOnExecutor 方 法 来 并 行 地 执 
TES ° 


11.2.2 ”AsyncTask 的 工作 原理 


为 了 分 析 AsyncTask 的 工作 原理 ， 我 们 从 它 的 execute 方 法 开始 分 
析 ，execute 方 法 又 会 调用 executeOnExecutor 方 法 ， 它 们 的 实现 如 下 所 
AR o 


public final AsyncTask<Params, Progress, Result> 


execute(Params... params) { 


在 上 面 的 代码 中 ，sDefaultExecutor 实 际 上 是 一 个 串 行 的 线程 池 ， 
一 个 进程 中 所 有 的 AsyncTask 全 部 在 这 个 串 行 的 线程 池 中 排队 执行 ， 这 
个 排队 执行 的 过 程 后 面 会 再 进行 分 机。 在 executeOnExecutor 方 法 中 ， 
AsyncTask 的 onPreExecute 方 法 最 先 执行 ， 然 后 线程 池 开 始 执行 。 下 面 
分 析 线 程 池 的 执行 过 程 ， 如 下 所 示 。 


J 
protected synchronized void scheduleNext() { 
if ((mActive = mTasks.poll()) != null) { 


THREAD_POOL_EXECUTOR.execute(mActive); 


} 


从 SerialExecutor 的 实现 可 以 分 析 AsyncTask 的 排队 执行 的 过 程 。 首 
完 系统 会 把 AsyncTask 的 Params 参 数 封装 为 FutureTask 对 象 ，FutureTask 
是 一 个 并 发 类 ， 在 这 里 它 充 当 了 Runnable 的 作用 。 接 着 这 个 FutureTask 
会 区 给 SerialExecutor 的 execute 方 法 去 处 理 ，SerialExecutor 的 execute 方 
法 首先 会 把 FutureTask 对 象 插入 到 任务 队列 mTasks 中 ， 如 采 这 个 时 候 没 
有 正在 活动 的 AsyncTask 任 务 ， 那 么 整 会 调用 SerialExecutor 的 
scheduleNext 方 法 来 执行 下 一 个 AsyncTask 任 务 。 同 时 当 一 个 AsyncTask 
任务 执行 完 后 ，AsyncTask 会 继续 执行 其 他 任务 直到 所 有 的 任务 都 被 执 
行为 止 ， 从 这 一 点 可 以 看 出 ， 在 默认 情况 下 ，AsyncTask 是 串 行 执行 
时 。 


AsyncTask 中 有 两 个 线程 池 ( SerialExecutor 和 
THREAD_POOL_EXECUTOR) 和 一 个 Handler \InternalHandler) ， 其 
中 线程 池 SerialExecutor 用 于 任务 的 排队 ， 而 线程 池 
THREAD_ POOL_EXECUTOR 用 于 真正 地 执行 任务 ，InternalHandler 用 
于 将 执行 环境 从 线程 池 切 换 到 主线 程 ， 关 于 线程 池 的 概念 将 在 第 11.3 
忆 中 详细 介绍 ， 其 本 质 仍然 是 线程 的 调用 过 程 。 在 AsyncTask 的 构造 方 
法 中 有 如 下 这 么 一 段 代码 ， 由 于 FutureTask 的 run 方 法 会 调用 mWorker 
的 call 方 法 ， 因 此 mWorker 的 call 方 法 最 终 会 在 线程 池 中 执行 。 


mworker = new WorkerRunnable<Params,Result>() { 
public Result call() throws Exception { 


mTaskInvoked.set(true); 


Process. setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND) ; 


//noinspection unchecked 


return postResult(doInBackground(mParans)); 


}; 


在 mWorker 的 call 方 法 中 ， 首 先 将 mTaskInvoked 设 为 true， 表 示 当 
前 任务 已 经 被 调用 过 了 ， 然 后 执行 AsyncTask 的 doInBackground 方 法 ， 
接着 将 其 返回 值 传递 给 postResult 方 法 ， 它 的 实现 如 下 所 示 。 


private Result postResult(Result result) { 
@SuppressWarnings("unchecked" ) 

Message message = 
sHandler .obtainMessage(MESSAGE_POST_RESULT, new 
AsyncTaskResult<Result>(this, result) ); 

message.sendToTarget(); 


return result; 


在 上 面 的 代码 中 ，postResult 万 法 会 通过 sHandler 发 送 一 个 
MESSAGE_POST_RESULT 的 消息 ， 这 个 sHandler 的 定义 如 下 所 示 。 


private static final InternalHandler sHandler = new 


InternalHandler(); 


private static class InternalHandler extends Handler { 


@SuppressWarnings({"unchecked", "RawUseOfParameterizedType" } ) 
@Override 
public void handleMessage (Message msg) { 
AsyncTaskResult result = (AsyncTaskResult) 
msg.obj; 
switch (msg.what) { 
case MESSAGE_POST_RESULT: 


// There is only one result 


result.mTask.finish(result.mData[0]); 
break; 


case MESSAGE_POST_PROGRESS: 


result.mTask.onProgressUpdate(result.mData); 


break; 


可 以 发 现 ，sHandler 是 一 个 静态 的 Handler 对 象 ， 为 了 能 够 将 执行 
环境 切换 到 主线 程 ， 这 就 要 求 sHandler 这 个 对 象 必 须 在 主线 程 中 创 
建 。 由 于 静态 成 员 会 在 加 载 类 的 时 候 进 行 初始 化 ， 因 此 这 束 变 相 要 求 
AsyncTask 的 类 必须 在 主线 程 中 加 载 ， 否 则 同一 个 进程 中 的 AsyncTask 
都 将 无 法 正常 工作 。sHandler 收 到 MESSAGE_POST_RESULT 这 个 消息 

百 会 调用 AsyncTask 的 finish 方 法 ， 如 下 所 示 。 


private void finish(Result result) { 
if (isCancelled()) { 
onCancelled( result); 
} elese 4 
onPostExecute( result); 


} 
mStatus = Status.FINISHED; 


} 


AsyncTask 的 finish 方 法 的 逻辑 比较 简单 ， 如 有 果 AsyncTask 补 取消 执 
TI., ABARCA onCancelled Y, AMIA E Yi A onPostExecute 77 
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通过 分 析 AsyncTask 的 源码 ， 可 以 进一步 确定 ， == 3.0 
始 ， 默 认 情 况 下 AsyncTask 的 确 是 串 行 执行 的 ， 在 这 一 系列 实验 
来 证 实 这 个 判断 。 


请 看 如 下 实验 代码 ， 代 码 很 简单 ， 束 是 单 击 按钮 的 时 候 同时 执行 5 
个 AsyncTask 任 务 ， 每 个 AsyncTask 会 休 SORE ATEN Mi a 
每 个 AsyncTask 执 行 结束 的 时 间 打 印 出 来 ,这样 我 们 就 能 观察 出 
AsyncTask 到 底 是 串 行 执行 还 是 并 行 执行 。 


@Override 
public void onClick(View v) { 
if (v == mButton) { 
new MyAsyncTask("AsyncTask#1").execute(""); 


new MyAsyncTask("AsyncTask#2").execute(""); 


df.format(new Date())); 


} 
i 


分 别 在 Android 4.1.14H Android 2.3.3 471124 EZTET, RART 
前 面 的 描述 ，AsyncTask 在 4.1.1 上 应 该 是 串 行 的 ， 在 2.3.3 上 应 该 是 并 行 
的 ， 到 底 是 不 是 这 样 呢 ? 请 看 下 面 的 运行 结 


Android 4.1.1 上 执行 : 如 图 11-1 所 示 ，5 个 AsyncTask 共 耗 时 15s 且 
时 间 间 隔 为 38， 很 显然 是 串 行 执行 的 。 


Application 


图 11-1 AsyncTask 在 Android 4.1.1 上 的 执行 顺序 


Android 2.3.3 上 执行 : 如 图 11-2 所 示 ，5 个 AsyncTask 的 结束 时 间 
是 一 样 的 ， 很 显然 是 并 行 执行 的 。 


Application 


图 11-2 AsyncTask#E Android 2.3.3 上 的 执行 顺序 


为 了 让 AsyncTask 可 以 在 Android 3.0 及 以 上 的 版 本 上 并 行 ， 可 以 采 
FA AsyncTask 的 executeOnExecutor 方 法 ， 需 要 注意 的 是 这 个 方法 是 
Android 3.0 新 添加 的 方法 ， 并 不 能 在 低 版 本 上 使 用 ， 如 下 所 示 。 


@TargetApi(Build.VERSION_CODES.HONEYCOMB) 
@Override 
public void onClick(View v) { 
if (v == mButton) { 
if (Build.VERSION.SDK_INT => 
Build. VERSION_CODES.HONEYCOMB) { 
new MyAsyncTask("AsyncTask#1"). 
executeOnExecutor (AsyncTask. THREAD_POOL_EXECUTOR, ""); 
new MyAsyncTask("AsyncTask#2"). 
executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR,""); 
new MyAsyncTask("AsyncTask#3"). 
executeOnExecutor (AsyncTask. THREAD_POOL_EXECUTOR, ""); 
new MyAsyncTask("AsyncTask#4"). 
executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR,""); 
new MyAsyncTask("AsyncTask#5"). 
executeOnExecutor (AsyncTask. THREAD_POOL_EXECUTOR, ""); 
} 


private static class MyAsyncTask extends 
AsyncTask<String, Integer,String> { 
private String mName = "AsyncTask"; 
public MyAsyncTask(String name) { 
super(); 
mName = name; 


} 


@Override 


在 Android 4.1.1 的 设备 上 


运行 上 述 程序 ， 日 志 如 图 11-3 所 示 ， 很 显 


然 ， 我 们 的 目的 达到 了 ， 成 功 地 让 AsyncTask 在 4.1.1 的 手机 上 并 行 起 来 


了 。 
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图 11-3 ”AsyncTask 的 executeOnExecutor 方 法 的 作用 


Tag 

AsyncTaskTest 
AsyncTaskTest 
AsyncTaskTest 
AsyncTaskTest 
AsyncTaskTest 


Text 


AsyncTask#lexecute finish at 2013-12-27 01:52:40 
AsyncTask#2execute finish at 2013-12-27 01:52:40 
AsyncTask#4execute finish at 2013-12-27 01:52:40 
AsyncTask#3execute finish at 2013-12-27 01:52:40 
AsyncTask#Sexecute finish at 2013-12-27 01:52:40 


11.2.3 HandlerThread 


HandlerThread 继承 了 Thread ， 它 是 一 种 可 以 使 用 Handler 的 
Thread， 写 的 实现 也 很 帘 单 ， 了 驶 是 在 run 方 法 中 通过 Looperprepare(0) 来 
创建 消息 队列 ， 并 通过 Looperloop0 来 开局 消息 循环 ， 这 样 在 实际 的 使 
H P aot 7047 HandlerThread ¥ 81) Handler [ ° HandlerThreadHJrun 7 
法 如 下 所 示 。 


public void run() { 
mTid = Process.myTid(); 
Looper .prepare(); 
synchronized (this) { 
mLooper = Looper.myLooper(); 
notifyAll(); 
} 
Process.setThreadPriority(mPriority); 
onLooperPrepared(); 
Looper.loop(); 
mTid = -1; 
} 


从 HandlerThread 的 实现 来 看 ， 它 和 普通 的 Thread 有 显著 的 不 同 之 
处 。 普 通 Thread 主 要 用 于 在 rm 方法 中 执行 一 个 耗 时 任务 ， 而 
HandlerThread 在 内 部 创建 了 消息 队列 ， 外 界 需 要 通过 Handler 的 消息 方 
式 来 通知 HandlerThread 执 行 一 个 具体 的 任务 。HandlerThread 是 一 个 很 
有 用 的 类 ， 它 在 Android 中 的 一 个 具体 的 使 用 场景 是 IntentService， 
IntentService 将 在 11.2.4 节 中 进行 介绍 。 由 于 HandlerThread 的 run 方 法 是 


一 个 无 限 循环 ， 因 此 当 明 确 不 需要 再 使 用 HandlerThread 时 ， 可 以 通过 
它 的 quit 或 者 quitSafely 方 法 来 终止 线程 的 执行 ， 这 是 一 个 良好 的 编程 
习惯 。 


11.2.4 IntentService 


IntentService 是 一 种 特殊 的 Service， 它 继承 了 Service 并 且 它 是 一 个 
抽象 类 ， 因 此 必须 创建 它 的 子 类 才能 使 用 mntentService。IntentService 
可 用 于 执行 后 台 耗 时 的 任务 ， 当 任务 执行 后 它 会 自动 停止 ， 同 时 由 于 
IntentService 是 服务 的 原因 ， 这 导致 它 的 优先 级 比 单纯 的 线程 要 高 很 
多 ， 所 以 IntentService 比 较 适合 执行 一 些 高 优先 级 的 后 台 任 务 ， 因 为 它 
优先 级 高 不 容易 被 系统 杀 死 。 在 实现 上 ，IntentService 封 装 了 
HandlerThread 和 Handler， 这 一 点 可 以 从 它 的 onCreate 方 法 中 看 出 来 ， 
ROR BTA > 


public void onCreate() { 
// TODO: It would be nice to have an option to hold a 
partial wakelock 
// during processing,and to have a static 
startService(Context, Intent) 
// method that would launch the service & hand off a 
wakelock. 
super.onCreate(); 
HandlerThread thread = new 
HandlerThread("IntentService[" + mName + "]"); 


thread.start(); 


mServiceLooper = thread.getLooper(); 


mServiceHandler = new ServiceHandler(mServiceLooper); 


A 


4 IntentService 被 第 一 次 启动 时 ， 它 的 onCreate 方 法 会 被 调用 ， 
onCreate 方 法 会 创建 一 个 HandlerThread， 然 后 使 用 它 的 Looper 来 构造 
一 个 Handler 对 象 mServiceHandler， 这 样 通过 mServiceHandler 发 送 的 消 
县 最 终 都 会 在 HandlerThread 中 执行 ， 从 这 个 角度 来 看 ，IntentService 也 
可 以 用 于 执行 后 台 任 务 。 每 次 启动 IntentService， 它 的 onStartCommand 
方法 就 会 调用 一 次 ，IntentService 在 onStartCommand 中 处 理 每 个 后 台 任 
务 的 Intent。 下 面 看 一 下 onStartCommand 方 法 是 如 何 处 理 外 界 的 Intent 
的 ，onStartCommand 调 用 了 onStart，onStart 方 法 的 实现 如 下 所 示 。 


public void onStart(Intent intent,int startld) { 
Message msg = mServiceHandler.obtainMessage(); 
msg.argi = startId; 
msg.obj = intent; 
mServiceHandler. sendMessage(msg); 


} 


可 以 看 出 ，IntentService 仅 仅 是 通过 mServiceHandler 发 送 了 一 个 消 
fA, 1X75 ASE HandlerThread FAE © mServiceHandler 2 75 Ja 
后 ， 会 将 Intent 对 和 象 传递 给 onHandleIntent 方 法 去 处 理 。 注 意 这 个 Intent 
对 象 的 内 容 和 外 界 的 startService(intent) 中 的 intent 的 内 容 是 完全 一 致 
的 ， 通 过 这 个 Intent 对 象 即 可 解析 出 外 界 局 动 IntentService 时 所 传递 的 
参数 ， 通 过 这 些 参 数 就 可 以 区 分 具体 的 后 台 任 务 ， 这 样 在 
onHandleIntent 方 法 中 整 可 以 对 不 同 的 后 台 任 务 做 处 理 了 。 当 
onHandleIntent 方 法 执行 结束 后 ，IntentService 会 通过 stopSelf(int startId) 


方法 来 尝试 集 止 服务 。 这 里 之 所 以 采用 stopSelf(int startId) 而 不 是 
stopSelf() 来 停止 服务 ， 那 是 因为 stopSelf0 会 立刻 停止 服务 ， 而 这 个 时 
候 可 能 还 有 其 他 消息 未 处 理 ，stopSelf(int start1d) 则 会 等 待 所 有 的 消息 
都 处 理 完毕 后 才 终止 服务 。 一 般 来 说 ，stopSelf(int startId) 在 尝试 停止 
服务 之 前 会 判断 最 近 局 动 服务 的 次 数 是 否 和 startId 相 等 ， 如 采 相 等 就 
立刻 停止 服务 ， 不 相等 则 不 停止 服务 ， 这 个 策略 可 以 从 AMS 的 
stopServiceToken 方 法 的 实现 中 找到 依据 ， 读 者 感 兴趣 的 话 可 以 目 行 查 
看 源码 实现 。ServiceHandler 的 实现 如 下 所 示 。 


private final class ServiceHandler extends Handler { 
public ServiceHandler(Looper looper) { 
super (looper); 
di 
@Override 
public void handleMessage(Message msg) { 
onHandleIntent( (Intent )msg.obj); 


stopSelf(msg.arg1); 


} 


IntentService 的 onHandleIntent 方 法 是 一 个 抽象 方法 ， 它 需要 我 们 
在 子 类 中 实现 ， 它 的 作用 是 从 Intent 参 数 中 区 分 具体 的 任务 并 执行 这 些 
任务 。 如 果 目 前 只 存在 一 个 后 台 任 务 ， 那 么 onHandleIntent 方 法 执行 完 
IX MES Ja, stopSelf(int startId) 束 会 直接 停止 服务 ;如 果 目 前 存在 多 
个 后 台 任 务 ， 那 么 当 onHandleIntent 方 法 执行 完 最 后 一 个 任务 时 ， 
stopSelf(int start1d) 才 会 直接 停止 服务 。 男 外 ， 由 于 每 执行 一 个 后 台 任 
务 就 必须 启动 一 次 IntentService， 而 IntentService 内 部 则 通过 消息 的 方 
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的 ， 这 就 意味 着 IntentService 也 是 顺序 执行 后 台 任 务 的 ， 当 有 多 个 后 台 
任务 同时 存在 时 ， 这 些 后 台 任 务 会 按照 外 界 发 起 的 顺序 排队 执行 。 


下 面 通 过 一 个 示例 来 进一步 说 明 IntentService 的 工作 方式 ， 首 先 派 
生 一 个 IntentService 的 子 类 ， 比 如 LocalIntentService， 它 的 实现 如 下 所 


— 
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super .onDestroy(); 


这 E 对 LocalIntentService 的 实现 做 一 下 人 简单 的 说 明 。 在 
onHandleIntent 方 法 中 会 从 参数 中 解析 出 后 台 任 务 的 标识 ， 即 
task_action 字 段 所 代表 的 内 容 ， 然 后 根据 不 同 的 任务 标识 来 执行 具体 
的 后 台 任 务 。 这 里 为 了 简单 起 见 ， 直 接 通过 SystemClock.sleep(3000) 来 
休眠 3000 训 秒 从 而 模拟 一 种 耗 时 的 后 台 人 任务， 另外 为 了 验证 
IntentService 的 停止 时 机 ， 这 里 在 onDestroy0 中 打印 了 一 句 日 志 。 
LocalIntentService 实 现 完成 了 以 后 ， 束 可 以 在 外 界 请 求 执行 后 人 台 任 务 
了 ， 在 下 面 的 代码 中 先后 发 起 了 3 个 后 人 台 任 务 的 请 求 : 


Intent service = new Intent(this,LocallntentService.class); 
service.putExtra("task_action","com.ryg.action.TASK1"); 
startService(service); 
service.putExtra("task_action","com.ryg.action.TASK2"); 
startService(service); 
service.putExtra("task_action","com.ryg.action.TASK3"); 


startService(service); 


运行 程序 ， 观 察 日 志 ， 如 下 所 示 。 


05-17 17:08:23.186 E/dalvikvm(25793): threadid=11: calling 
run(),name=IntentService[LocalIntentService ] 
05-17 17:08:23.196 D/LocallntentService(25793): receive 
task :com.ryg.action.TASK1 


05-17 17:08:26.199 D/LocalIntentService(25793): handle 


task: com.ryg.action.TASK1 
05-17 17:08:26.199 D/LocallntentService(25793): receive 
task :com.ryg.action.TASK2 
05-17 17:08:29.192 D/LocallntentService(25793): receive 
task :com.ryg.action.TASK3 
05-17 17:08:32.205 D/LocallntentService(25793): service 
destroyed. 
05-17 17:08:32.205 E/dalvikvm(25793): threadid=11: 


exiting, name=IntentService[LocallntentService] 


从 上 面 的 日 志 可 以 看 出 ， 三 个 后 台 任 务 是 排队 执行 的 ， GO, 
行 顺序 瓯 是 它们 发 起 请 求 对 的 顺序 即 TASK1、TASK2、TASK3 ° 
外 一 点 就 是 当 TASK3 执 行 完 毕 后 ， pe 
从 日 志 中 可 以 看 出 LocalIntentService 执 行 了 onDestroy()， = 意味 着 服 
务 正在 停止 。 


11.3 ” Android 中 的 线程 池 


所 到 线程 池 融 必须 先 说 一 下 线程 池 的 好 处 ， 相 信 读 者 都 有 所 体 
会 ， 线 程 池 的 优点 可 以 概括 为 以 下 三 点 : 


(1) 重用 线程 池 中 的 线程 ， 避 免 因 为 线程 的 创建 和 销毁 所 带 来 的 
性 能 开销 。 


(2) 能 有 效 控制 线程 池 的 最 大 并 发 数 ， 避 免 大 量 的 线程 之 间 因 互 
相 抢 占 系统 资源 而 导致 的 阻塞 现象 。 


(3) 能 够 对 线程 进行 简单 的 管理 ， 并 提供 定时 执行 以 及 指定 间隔 
循环 执行 等 功能 。 


Android 中 的 线程 池 的 概念 来 源 于 Java 中 的 Executor，Executor 是 一 
个 接口 ， 真 正 的 线程 池 的 实现 为 ThreadPoolExecutor 。 
ThreadPoolExecutor 提 供 了 一 系列 参数 来 配置 线程 池 ， 通 过 不 同 的 参数 
可 以 创建 不 同 的 线程 池 ， 从 线程 池 的 功能 特性 上 来 说 ，Android 的 线程 
池 主 要 分 为 4 类 ， 这 4 类 线程 池 可 以 通过 Executors 所 提供 的 工厂 方法 来 
得 到 ， 具 体会 在 11.3.2 广 中 进行 详细 介绍 。 由 于 Android 中 的 线程 江都 
是 直接 或 者 间接 通过 配置 ThreadPoolExecutor 来 实现 的 ， 因 此 在 介绍 它 
们 之 前 需要 先 介 绍 ThreadPoolExecutor。 


11.3.1 ThreadPoolExecutor 


ThreadPoolExecutor 是 线程 池 的 真正 实现 ， 它 的 构造 方法 提供 了 一 
系列 参数 来 配置 线程 池 ， 下 面 介 绍 ThreadPoolExecutor 的 构造 方法 中 各 
个 参数 的 舍 义 ， 这 些 参数 将 会 直接 影响 到 线程 池 的 功能 特性 ， 下 面 是 
ThreadPoolExecutor 的 一 个 比较 常用 的 构造 方法 。 


public ThreadPoolExecutor(int corePoolSize, int 


maximumPoolSize, 
long 
keepAliveTime, 
TimeUnit 
unit, 


BlockingQueue<Runnable> workQueue, 


ThreadFactory 


threadFactory) 


corePoolSize 


线程 池 的 核心 线程 数 ， 默 认 情 况 下 ， 核 心 线程 会 在 线程 池 中 一 直 
存活 ， 即 使 它们 处 于 闲置 状态 。 如 果 将 ThreadPoolExecutor 的 
allowCoreThreadTimeOut 属 性 设置 为 tue， 那 么 内 置 的 核心 线程 在 等 待 
新 任务 到 来 时 会 有 超时 策略 ， 这 个 时 间 间 陋 由 keepAliveTime 所 指定 ， 
当 等 每 时 间 超 过 keepAliveTime 所 指定 的 时 长 后 ， 核 心 线程 束 会 被 终 
上 o 


maximumPoolSize 


线程 池 所 能 容纳 的 最 大 线程 数 ， 当 活动 线程 数 达 到 这 个 数值 后 ， 
后 续 的 新 任务 将 会 被 阻塞 。 


keepAliveTime 


非 核 心 线程 用 置 时 的 超时 时 长 ， 超 过 这 个 时 长 ， 非 核心 线程 就 会 
被 回收 。 当 ThreadPool-Executor 的 allowCoreThreadTimeOut 属 性 设置 为 
true 时 ，keepAliveTime 同 样 会 作用 于 核心 线程 。 


unit 


用 于 指定 keepAliveTime 参 数 的 时 间 单 位 ， 这 是 一 个 枚 举 ， 常 用 的 
有 TimeUnit. MILLISECONDS (3%) > TimeUnitSECONDS (FF) 以 
M TimeUnit.MINUTES (44H) Eo 


workQueue 


线程 池 中 的 任务 队列 ， 通 过 线程 池 的 execute 方 法 提交 的 Runnable 
对 象 会 存储 在 这 个 参数 中 。 


threadFactory 


线程 工厂 ， 为 线程 池 提 供 创建 新 线程 的 功能 。ThreadFactory 是 一 
个 接口 ， 它 只 有 一 个 方法 : Thread newThread(Runnable r) ° 


除了 上 面 的 这 些 主 要 参数 外 ，ThreadPoolExecutor 还 有 一 个 不 常用 
的 参数 Rejected-ExecutionHandler handler。 当 线程 池 无 法 执行 新 任务 
时 ， 这 可 能 是 由 于 任务 队列 已 满 或 者 是 无 法 成 功 执行 任务 ， 这 个 时 候 
ThreadPoolExecutor 会 调用 handler 的 rejectedExecution 方 法 来 通知 调用 
者 ， 默 认 人 情况 下 rejectedExecution 方法 会 直接 抛 出 一 个 
RejectedExecution-Exception E ThreadPoolExecutor 为 
RejectedExecutionHandler 提供 了 几 个 可 选 值 : CallerRunsPolicy ` 
AbortPolicy ` DiscardPolicy Al DiscardOldestPolicy, $% "P AbortPolicy zŒ 
默认 值 ， 它 会 直接 抛 出 RejectedExecutionException， 由 于 handler 这 个 
参数 不 常用 ， 这 里 束 不 再 具体 介绍 了 。 


ThreadPoolExecutor 执 行 任 务 时 大 致 革 循 如 下 规则 ; 


(1) 如 果 线 程 池 中 的 线程 数量 未 达到 核心 线程 的 数量 ， 那 么 会 直 
接 启动 一 个 核心 线程 来 执行 任务 。 


(2) 如 果 线 程 池 中 的 线程 数量 已 经 达到 或 者 超过 核心 线程 的 数 
量 ， 那 么 任务 会 被 插入 到 任务 队列 中 排队 等 待 执行 。 


(3) 如 果 在 步 又 2 中 无 法 将 任务 插入 到 任务 队列 中 ， 这 往往 是 由 
于 任务 队列 已 满 ， 这 个 时 候 如 果 线 程 数量 未 达到 线程 池 规 定 的 最 大 


值 ， 那 么 会 立刻 局 动 一 个 非 核心 线程 来 执行 任务 。 


(4) 如 果 步 骤 3 中 线程 数量 已 经 达到 线程 池 规定 的 最 大 值 ， 那 么 
束 拒绝 执行 此 £ & ， ThreadPoolExecutor 会 调用 
RejectedExecutionHandler 的 rejectedExecution 方 法 来 通知 调 用 者 。 


ThreadPoolExecutor 的 参数 配置 在 AsyncTask 中 有 明显 的 体现 ， 下 
面 是 AsyncTask 中 的 线程 池 的 配置 情况 : 


private static final int CPU_COUNT = 
Runtime.getRuntime().availableProcessors(); 
private static final int CORE_POOL_SIZE = CPU_COUNT + 1; 
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 
ited 
private static final int KEEP_ALIVE = 1; 
private static final ThreadFactory sThreadFactory = new 
ThreadFactory() { 
private final AtomicInteger mCount = new 
AtomicInteger (1); 
public Thread newThread(Runnable r) { 
return new Thread(r,"AsyncTask #" + 
mCount .getAndIncrement()); 
} 
}; 


private static final BlockingQueue<Runnable> sPoolWorkQueue 


new LinkedBlockingQueue<Runnable>(128); 


JE 


* An {@link Executor} that can be used to execute tasks 
in parallel. 
2% 
public static final Executor THREAD_POOL_EXECUTOR 
= new 
ThreadPoolExecutor (CORE_POOL_SIZE, MAXIMUM_POOL_SIZE,KEEP_ 


ALIVE, TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory); 


从 上 面 的 代码 可 以 知道 ， AsyncTask 对 
THREAD POOL _EXECUTOR 这 个 线程 池 进行 了 配置 ， 配 置 后 的 线程 
池 规格 如 下 : 


。 核心 线程 数 等 于 CPU 核心 数 +1; 

。 线程 池 的 最 大 线程 数 为 CPU 核心 数 的 2 倍 +1; 

。 核心 线程 无 超时 机 制 ， 非 核心 线程 在 闲置 时 的 超时 时 间 为 1 秒 ; 
。 任务 队列 的 容量 为 128。 


11.3.2 ”线程 池 的 分 类 


在 11.3.1 万 中 对 ThreadPoolExecutor 的 配置 细节 进行 了 详细 的 介 
绍 ， 本 节 将 接着 介绍 Android 中 最 常见 的 四 类 具有 不 同 功 能 特性 的 线程 
池 ， 它 们 都 直接 或 间接 地 通过 配置 ThreadPoolExecutor 来 实现 目 己 的 功 
能 特性 ， 这 四 类 线程 池 分 别 是 FixedThreadPool、CachedThreadPool、 
ScheduledThreadPool 以 及 SingleThreadExecutor ° 


1. FixedThreadPool 


通过 Executors 的 newFixedThreadPool 方 法 来 创建 。 它 是 一 种 线程 
数量 固定 的 线程 池 ， 当 线程 处 于 空闲 状态 时 ， 它 们 并 不 会 被 回收 ， 除 
非 线程 池 被 关闭 了 。 当 所 有 的 线程 都 处 于 活动 状态 时 ， 新 任务 都 会 处 
等 竺 状态 ， 直 到 有 线程 空 采 出 来 。 由 于 FixedThreadPool 只 有 核心 线 
程 并 且 这 些 核心 线程 不 会 被 回收 ， 这 意味 着 它 能 够 更 加 快速 地 啊 应 外 
界 的 请 求 。newFixedThreadPool 方 法 的 实现 如 下 ， 可 以 发 现 
FixedThreadPool 中 只 有 核心 线程 并 且 这 些 核 心 线程 没有 超时 机 制 ， 另 
外 任务 队列 也 是 没有 大 小 限制 的 。 


public static ExecutorService newFixedThreadPool(int 
nThreads) { 


return new ThreadPoolExecutor(nThreads,nThreads, 
OL, TimeUnit .MILLISECONDS, 


new LinkedBlockingQueue<Runnable>()); 


} 
2. CachedThreadPool 


通过 Executors 的 newCachedThreadPool 方 法 来 创建 。 它 是 一 种 线程 
数量 不 定 的 线程 池 ， 它 只 有 非 核心 线程 ， 并 有 旦 其 最 大 线程 数 为 
IntegerMAX_VALUE。 由 于 IntegerMAX_VALUE 是 一 个 很 大 的 数 ， 实 
际 上 就 相当 于 最 大 线程 数 可 以 任意 大 。 当 线程 池 中 的 线程 都 处 于 活动 
状态 时 ， 线 程 池 会 创建 新 的 线程 来 处 理 新 任务 ， 否 则 就 会 利用 空 几 的 
线程 来 处 理 新 任务 。 线 程 池 中 的 空 几 线程 都 有 超时 机 制 ， 这 个 超时 时 
长 为 60 秒 ， 超 过 60 秒 闲置 线程 殉 会 被 回收 。 和 FixedThreadPool 不 同 的 
是 ，CachedThreadPool 的 任务 队列 其 实 相 当 于 一 个 空 集合 ， 这 将 导致 


任何 任务 都 会 立即 被 执行 ， 因 为 在 这 种 场景 下 SynchronousQueue 是 无 
法 插入 任务 的 。SynchronousQueue 是 一 个 非常 特殊 的 队列 ， 在 很 多 情 
况 下 可 以 把 它 人 简单 理解 为 一 个 无 法 存储 元 素 的 队列 ， 由 于 它 在 实际 中 
较 少 使 用 ， 这 里 束 不 深入 探讨 它 了 。 从 CachedThreadPool 的 特性 来 
看 ， 这 类 线程 池 比 较 适 合 执 行 大 量 的 耗 时 较 少 的 任务 。 当 整个 线程 池 
都 处 于 内 置 状态 时 ， 线 程 池 中 的 线程 都 会 超时 而 被 集 止 ， 这 个 时 候 
CachedThreadPool 之 中 实际 上 是 没有 任何 线程 的 ， 它 几乎 是 不 占用 任 
何 系统 资源 的 。newCachedThreadPoo] 方 法 的 实现 如 下 所 示 。 


public static ExecutorService newCachedThreadPool() { 
return new ThreadPoolExecutor(0, Integer .MAX_VALUE, 
60L, TimeUnit.SECONDS, 
new 
SynchronousQueue<Runnable>()); 


} 
3. ScheduledThreadPool 


通过 Executors 的 newScheduledThreadPool 方 法 来 创建 。 它 的 核心 线 
程 数 量 是 固定 的 ， 而 非 核心 线程 数 是 没有 限制 的 ， 并 且 当 非 核心 线程 
闲置 时 会 被 立即 回收 。ScheduledThreadPool 这 类 线程 池 主 要 用 于 执行 
定时 任务 和 具有 固定 周期 的 重复 任务 ，newScheduledThreadPool 方 法 的 
实现 如 下 所 示 。 


public static ScheduledExecutorService 
newScheduledThreadPool(int 
corePoolSize) { 


return new ScheduledThreadPoolExecutor(corePoolSize); 


i 


public ScheduledThreadPoolExecutor(int corePoolSize) { 
super(corePoolSize, Integer .MAX_VALUE, ©, NANOSECONDS, 


new DelayedWorkQueue()); 


4. SingleThreadExecutor 


通过 Executors 的 newSingleThreadExecutor 方 法 来 创建 。 这 类 线程 
池内 部 只 有 一 个 核心 线程 ， 它 确保 所 有 的 任务 都 在 同一 个 线程 中 按 顺 
序 执行 。SingleThreadExecutor 的 意义 在 于 统一 所 有 的 外 界 任 务 到 一 个 
线程 中 ， 这 使 得 在 这 些 任 务 之 间 不 需要 处 理 线程 同步 的 问题 。 
newSingleThreadExecutor 方 法 的 实现 如 下 所 示 。 


public static ExecutorService newSingleThreadExecutor() { 
return new FinalizableDelegatedExecutorService 


(new ThreadPoolExecutor(1,1, 


OL, TimeUnit .MILLISECONDS, 
new 
LinkedBlockingQueue<Runnable>())); 


i 


上 面 对 Android 中 常见 的 4 种 线程 池 进 行 了 详细 的 介绍 ， 除 了 上 面 
系统 提供 的 4 类 线程 池 以 外 ， 也 可 以 根据 实际 需要 灵活 地 配置 线程 池 。 
下 面 的 代码 演示 了 系统 预 置 的 4 种 线程 池 的 典型 使 用 方法 。 


12% ”Bitmap 的 加 载 和 Cache 


本 章 的 主题 是 Bitmap 的 加 载 和 Cache， 主 要 包含 三 个 方面 的 内 容 。 
首先 讲述 如 何 有 效 地 加 载 一 个 Bitmap ， 这 是 一 个 很 有 意义 的 话题 ， 由 
于 Bitmap 的 特殊 性 以 及 Android 对 单个 应 用 所 施加 的 内 存 限制 ， 比 如 
16MB， 这 导致 加 载 Bitmap 的 时 候 很 容易 出 现 内 存 洲 出 。 下 面 这 个 异 
言 筷 在 开发 中 应 该 时 常 遇 到 |: 


java.lang.OutofMemoryError: bitmap size exceeds VM budget 


因此 如 何 高 效 地 加 载 Bitmap 是 一 个 很 重要 也 很 容易 被 开发 者 忽视 
的 问题 。 


接着 介绍 Android 中 常用 的 缓存 策略 ， 缓 存 策 上 略 是 一 个 通用 的 思 
想 ， 可 以 用 在 很 多 场景 中 ， 但 是 实际 开发 中 经 常 需要 用 Bitmap 做 绥 
存 。 通 过 绥 存 策略 ， 我 们 不 需要 每 次 都 从 网 络 上 请 求 图 片 或 者 从 存储 
设备 中 加 载 图 片 ， 这 样 就 极 大 地 提高 了 图 厂 的 加 载 效 率 以 及 产品 的 用 
户 体 验 。 目 前 比较 常用 的 缓存 策略 是 LruCache 和 DiskLruCache， 其 中 
LruCache 常 被 用 做 内 存 缓存 ， 而 DiskLruCache 常 被 用 做 存储 缓存 。Lrmu 
是 Least Recently Used 的 缩写 ， 即 最 近 最 少 使 用 算法 ， 这 种 算法 的 核心 
思想 为 : 当 缓存 快 满 时 ， 会 淘汰 近期 最 少 使 用 的 缓存 目标 ， 很 显然 Lru 
算法 的 思想 是 很 容易 被 接受 的 。 


最 后 本 章 会 介绍 如 何 优 化 列表 的 卡 顿 现象 ，ListView 和 GridView 
由 于 要 加 载 大 量 的 子 视图 ， 当 用 户 快 速 滑动 时 就 容易 出 现 卡 顿 的 现 
象 ， 因 此 本 章 最 后 针对 这 个 问题 将 会 给 出 一 些 优 化 建议 。 


为 了 更 好 地 介绍 上 述 三 个 主题 ， 本 章 提供 了 一 个 示例 程序 ， 该 程 
序 会 尝试 从 网 络 加 载 大 量 图 片 并 在 GridView 中 显示 ， 可 以 发 现 这 个 程 
序 具 有 很 强 的 实用 性 ， 并 且 其 技术 细节 完全 黎 盖 了 本 章 的 三 个 主题 : 
图 片 加 载 、 缓 存 策略 、 列 表 的 滑动 流畅 性 ， 通 过 这 个 示例 程序 读者 可 
以 很 好 地 理解 本 章 的 全 部 内 容 并 能 够 在 实际 中 灵活 应 用 。 


12.1 Bitmap 的 高 效 加 载 


在 介绍 Bitmap 的 局 效 加 载 之 前 ， 先 说 一 下 如 何 加 载 一 个 Bitmap， 
Bitmap 在 Android 中 指 的 是 一 张 图 片 ， 可 以 是 png 格 式 也 可 以 是 jpg 等 其 
他 和 常见 的 图 片 格式 。 那 么 如 何 加 载 一 个 图 片 呢 ?BitmapFactory 类 提供 
了 四 类 方法 : decodeFile ` decodeResource > decodeStream 和 
decodeByteArray， 分 别 用 于 支持 从 文件 系统 、 资 源 、 输 入 流 以 及 字 市 
数组 中 加 载 出 一 个 Bitmap 对 象 ， 其 中 decodeFile 和 decodeResource 又 间 
接 调 用 了 decodeStream 方 法 ， 这 四 类 方法 最 终 是 在 Android 的 确 层 实现 
的 ， 对 应 着 BitmapFactory 类 的 几 个 native 方 法 。 


如 何 高 效 地 加 载 Bitmap 呢 ? 其 实 核心 思想 也 很 测 单 ， 那 融 是 采用 
BitmapFactory.Options 米 加 载 所 需 尺 寸 的 图 片 。 这 里 假设 通过 
ImageView 来 显示 图 片 ， 很 多 时 候 ImageView 并 没有 图 片 的 原始 尺寸 那 
么 大 ， 这 个 时 候 把 整个 图 片 加 载 进来 后 再 设 给 ImageView， 这 显然 是 
没 必 要 的 ， 为 ImageView 并 没有 办 法 显示 原始 的 图 片 。 通 过 
BitmapFactory.Options 就 可 以 按 一 定 的 来 样 率 来 加 载 缩小 后 的 图 片 ， 将 
缩小 后 的 图 片 在 ImageView 中 显示 ， 这 样 就 会 降低 内 存 占用 从 而 在 一 
定 程 度 上 避免 OOM， 提 高 了 Bitmap 加 载 时 的 性 能 。BitmapFactory 提 供 


的 加 载 图 片 的 四 类 方法 都 支持 BitmapFactory.Options 参 数 ， 通 过 它们 就 
可 以 很 方便 地 对 一 个 图 片 进行 采样 缩放 。 


if af BitmapFactory.Options &# iA, EB EAB TEN 

inSampleSize 参 数 ， 即 采样 率 。 当 inSampleSize 为 1 时 ， 采 样 后 的 图 片 大 
小 为 图 片 的 原始 大 小 ; 当 inSampleSize 大 于 1 时 ， 比 如 为 2， 那 么 采样 后 
的 图 片 其 视 / 高 均 为 原 图 大 小 的 112， 而 像素 数 为 原 图 的 114， 其 占有 的 
内 存 大 小 也 为 原 图 的 /4。 拿 一 张 1024x1024 像 素 的 图 片 来 说 ， 假 定 采 
用 ARGB8888 格 式 存 储 ， 那 么 它 占 有 的 内 存 为 1024x1024x4， 即 4MB， 
如 采 inSampleSize 为 2， 那 么 采样 后 的 图 片 其 内 存 占 用 只 
512x512x4， 即 1MB。 可 以 发 现 采样 率 inSampleSize 必 须 是 大 于 1 的 整 
数 图 片 才 会 有 缩小 的 效果 ， 并 且 采 样 率 同时 作用 于 宽 / 高 ， 这 将 导致 缩 
放 后 的 图 片 大 小 以 采样 率 的 2 次 方形 式 递 减 ， 即 缩放 比例 为 1/ 

LinSampleSize 的 2 次 方 ) ， 比 如 inSampleSize 为 4， 那 么 缩放 比例 就 是 
1/16。 有 一 种 特殊 情况 ， 那 就 是 当 inSampleSize 小 于 1 时 ， 其 作用 相当 
于 1， 即 无 缩放 效果 。 男 外 最 新 的 官方 文档 中 指出 ，inSampleSize 的 取 
值 应 该 总 是 为 2 的 指数 ， 比 如 1、2、4、8、16， 等 等 。 如 果 外 界 传递 给 
系统 的 inSampleSize 不 为 2 的 指数 ， 那 么 系统 会 问 下 取 整 并 选择 一 个 最 
接近 的 2 的 指数 来 代替 ， 比 如 3， 系 统 会 选择 2 来 代 奉 ， 但 是 经 过 验证 发 
现 这 个 结论 并 非 在 所 有 的 Android 版 本 上 都 成 立 ， 因 此 把 它 当 成 一 个 开 
发 建议 即 可 。 


考虑 以 下 实际 的 情况 ， 比 如 ImageView 的 大 小 是 100x100 像 素 ， 而 
图 片 的 原始 大 小 为 200x200， 那 么 只 需 将 采样 率 inSampleSize 设 为 2 即 
可 。 但 是 如 果 图 片 大 小 为 200x300 呢 ? 这 个 时 候 采样 率 还 应 该 选择 2， 
这 样 缩放 后 的 图 片 大 小 为 100x150 像 素 ， 仍 然 是 适合 ImageView 的 ， 如 


果 采 样 率 为 3， 那 么 缩放 后 的 图 片 大 小 束 会 小 于 ImageView 所 期 望 的 大 
小 ， 这 样 图片 束 会 被 拉 伸 从 而 导致 模糊 。 


通过 采样 率 即 可 有 效 地 加 载 图 片 ， 那 么 到 底 如 何 获 取 采 样 率 呢 ? 
获取 采样 率 也 很 价 单 ， 遭 循 如 下 流程 : 


(1) 将 BitmapFactory.Options 的 inJustDecodeBounds 参 数 设 为 true 


并 加 载 图 片 。 


(2) 从 BitmapFactory.Options 中 取出 图 片 的 原始 宽 高 信息 ， 它 们 
对 应 于 outWidth 和 outHeight 参 数 。 


(3) 根据 采样 率 的 规则 并 结合 目标 View 的 所 需 大 小 计算 出 采样 
inSampleSize ° 


(4) 将 BitmapFactory.Options 的 inJustDecodeBounds 参数 设 为 
false， 然 后 重新 加 载 图 片 。 


经 过 上 面 4 个 步骤 ， 加 载 出 的 图 片 束 是 最 终 缩放 后 的 岁 片 ， 当 然 也 
有 可 能 不 需要 缩放 。 这 里 说 明 一 下 inJustDecodeBounds 参 数 ， 当 此 参数 
设 为 true 时 ，BitmapFactory 只 会 解析 图 片 的 原始 宽 / 高 信息 ， 并 不 会 去 
真正 地 加 载 图 片 ， 所 以 这 个 操作 是 轻 量 级 的 。 另 外 需要 注意 的 是 ， 这 
个 时 候 BitmapFactory 获 取 的 图 片 宽 / 高 信息 和 图 片 的 位 置 以 及 程序 运行 
的 设备 有 关 ， 比 如 同一 张 图 片 放 在 不 同 的 drawable 目 孙 下 或 者 程序 运 
行 在 不 同 屏 幕 密度 的 设备 上 ， 这 都 可 能 导致 BitmapFactory 获 取 到 不 同 
的 结果 ， 之 所 以 会 出 现 这 个 现象 ， 这 和 Android 的 资源 加 载 机 制 有 关 ， 
相信 读者 平日 里 肯定 有 所 体会 ， 这 里 就 不 再 详细 说 明了 。 


将 上 面 的 4 个 流程 用 程序 来 实现 ， 就 产生 了 下 面 的 代码 : 


public static Bitmap 
decodeSampledBitmapFromResource(Resources res, int resld, 
int reqwidth,int reqHeight) { 
// First decode with inJustDecodeBounds=true to check 
dimensions 
final BitmapFactory.Options options = new 
BitmapFactory.Options(); 
options.inJustDecodeBounds = true; 
BitmapFactory.decodeResource(res, resId, options); 
// Calculate inSampleSize 
options. inSampleSize = 
calculateInSampleSize(options, reqwidth, reqHeight ) ; 
// Decode bitmap with inSampleSize set 
options.inJustDecodeBounds = false; 
return 
BitmapFactory.decodeResource(res, resid, options); 
} 
public static int calculateInSampleSize( 
BitmapFactory.Options options, int reqwWidth, int 
reqHeight) { 
// Raw height and width of image 
final int height = options.outHeight; 
final int width = options.outWidth; 
int inSampleSize = 1; 
if (height > reqHeight || width > reqwidth) { 
final int halfHeight = height / 2; 
final int halfwidth = width / 2; 


// Calculate the largest inSampleSize value that 
is a power of 2 and 
keeps both 
// height and width larger than the requested 
height and width. 
while ((halfHeight / inSampleSize) => reqHeight 
&& (halfwidth / inSampleSize) => reqwidth) 


inSampleSize *= 2; 


} 


return inSampleSize; 


有 了 上 面 的 两 个 方法 ， la ET 比如 
ImageView 所 期 望 的 图 片 大 小 为 100x100 像 素 ， 这 个 时 候 就 可 以 通过 如 
下 方式 高 效 地 加 载 并 显示 图 片 : 


mImageView.setImageBitmap ( 


decodeSampledBitmapFromResource(getResources(),R.id.myimage, 100 


,100)); 


除了 BitmapFactory 的 decodeResource 方 法 ， 其 他 三 个 decode 系 列 的 
方法 也 是 支持 采样 加 载 的 ， 并 且 处 理 方式 也 是 类 似 的 ,但 是 
decodeStream 方 法 稍微 有 点 特殊 ， 这 个 会 在 后 续 内 容 中 详细 介绍 。 通 
过 本 节 的 介绍 ， 读 者 应 该 能 很 好 地 掌握 这 种 高 效 地 加 载 图 片 的 方法 
了 o 


12.2 ” Android 中 的 缓存 策略 


缓存 策略 在 Android 中 有 着 广泛 的 使 用 场景 ， 尤 其 在 图 片 加 载 这 个 
场景 下 ， 绥 存 策略 就 变 得 更 为 重要 。 考 虑 一 种 场景 有 一 批 网 络 图 
厂 ， 需 要 下 载 后 在 用 户 界面 上 了 予以 显示 ， 这 个 场景 在 PC 环境 下 是 很 简 
单 的 ， 直 接 把 所 有 的 图 片 下 载 到 本 地 再 显示 即 可 ， 但 是 放 到 移动 设备 
上 就 不 一 样 了 。 不 管 是 Android 还 是 iO0S 设 备 ， 流 量 对 于 用 户 来 说 都 是 
一 种 宝贵 的 资源 ， 由 于 流量 是 收费 的 ， 所 以 在 应 用 开发 中 并 不 能 过 多 
地 消耗 用 户 的 流量 ， 否 则 这 个 应 用 肯定 不 能 被 用 户 所 接受 。 再 加 上 目 
前 国内 公共 场所 的 WiFi 普 及 率 并 不 算 太 高 ， 因 此 用 户 在 很 多 情况 下 手 
机 上 都 是 用 的 移动 网 络 而 非 WiFi， 因 此 必须 提供 一 种 解决 方案 来 解决 
流量 的 消耗 问题 。 


如 何 避 人 免 过 多 的 流量 消耗 呢 ? 那 就 是 本 市 所 要 讨论 的 主题 ， 绥 
存 。 当 程序 第 一 次 从 网 络 加 载 岁 片 后 ， 束 将 其 缓存 到 存储 设备 上 ， 这 
样 下 次 使 用 这 张 图 片 就 不 用 再 从 网 络 上 获取 了 ， 这 样 就 为 用 户 省 了 
流量 。 很 多 时 候 为 了 提高 应 用 的 用 户 体 验 ， 往 往 还 会 把 图 片 在 内 存 中 
再 缓存 一 份 ， 这 样 当 应 用 打算 从 网 络 上 请 求 一 张 图 片 时 ， 程 序 会 首先 
从 内 存 中 去 获取 ， 如 果 内 存 中 没有 那 束 从 存储 设备 中 去 获取 ， 如 果 存 
储 设备 中 也 没有 ， 那 束 从 网 络 上 下 载 这 张 图 片 。 因 为 从 内 存 中 加 载 图 
片 比 从 存储 设备 中 加 载 图 片 要 快 ， 所 以 这 样 既 提 高 了 程序 的 效率 又 为 
用 户 和 节约 了 不 必要 的 流量 开销 。 上 述 的 缓存 策略 不 仅仅 适用 于 图 片 ， 
也 适用 于 其 他 文件 类 型 。 


说 到 缓存 策略 ， 其 实 并 没有 统一 的 标准 。 一 般 来 襄 ， 绥 存 策 略 主 
要 包含 缓存 的 添加 、 获 取 和 删除 这 三 类 操作 。 如 何 添加 和 获取 缓存 这 
个 比较 好 理解 ， 那 么 为 什么 还 要 删除 缓存 呢 ? 这 是 因为 不 管 是 内 存 缓 


存 还 是 存储 设备 缓存 ， 它 们 的 缓存 大 小 都 是 有 限制 的 ， 因 为 内 存 和 请 
如 SD 卡 之 类 的 存储 设备 都 征 有 容量 限制 的 ， 因 此 在 使 用 缓存 时 总 是 要 
为 缓存 指定 一 个 最 大 的 容量 。 如 有 果 当 缓存 容量 满 了 ， 但 是 程序 还 需 

向 其 添加 缓存 ， 这 个 时 候 该 怎么 办 呢 ? 这 就 需要 删除 一 些 旧 的 缓存 并 
添加 新 的 缓存 ， 如 何 定义 缓存 的 新 日 这 束 是 一 种 策略 ， 不 同 的 策略 惑 
对 应 着 不 同 的 缓存 算法 ， 比 如 可 以 简单 地 根据 文件 的 最 后 修改 时 间 来 
定义 绥 存 的 新 旧 ， 当 绥 存 满 时 束 将 最 后 修改 时 间 较 早 的 缓存 移 除 ， 这 
忠 古 一 种 绥 存 算法 ， 但 是 这 种 算法 并 不 滤 很 完美 。 


目前 常用 的 一 种 缓存 算法 是 LRU (Least Recently Used) ，LRU 是 
近期 最 少 使 用 算法 ， 它 的 核心 思想 是 当 绥 存 满 时 ， 会 优先 淘汰 那些 近 
期 最 少 使 用 的 缓存 对 象 。 采 用 LRU 算 法 的 缓存 有 两 种 : LruCache 和 
DiskLruCache ，LruCache 用 于 实现 内 存 缓存 ， 而 DiskLruCache 则 充当 
了 存储 设备 缓存 ， 通 过 这 二 者 的 完美 结合 ， 残 可 以 很 方便 地 实现 一 个 
具有 很 高 实用 价值 的 ImageLoader。 本 市 首先 会 介绍 LruCache 和 
DiskLruCache， 然 后 利用 LruCache 和 DiskLruCache 来 实现 一 个 优秀 的 
ImageLoader， 并 且 提 供 一 个 使 用 ImageLoader 来 从 网 络 下 载 并 展示 
厂 的 例子 ， 在 这 个 例子 中 体现 了 ImageLoader 以 及 大 批量 网 络 图 厂 加 载 
所 涉及 的 大 量 技术 点 。 


12.2.1 LruCache 


LruCache 是 Android 3.1 所 提供 的 一 个 缓存 类 ， 通 过 support-v4 兼 容 
包 可 以 兼容 到 早期 的 Android 版 本 ， 目 前 Android 2.2 以 下 的 用 户 量 已 经 
很 少 了 ， 因 此 我 们 开发 的 应 用 兼容 到 Android 2.2 就 已 经 足够 了 。 为 了 


能 够 兼容 Android 2.2 版 本 ， 在 使 用 LruCache 时 建议 采用 support-v4 兼 容 
包 中 提供 的 LruCache， 而 不 要 直接 使 用 Android 3.1 提 供 的 LruCache ° 


LruCache 是 一 个 泛 型 类 ， 它 内 部 采用 一 个 LinkedHashMap 以 强 引 
用 的 方式 存储 外 界 的 缓存 对 象 ， 其 提供 了 get 和 put 方法 来 完成 缓存 的 获 
取 和 添加 操作 ， 当 缓存 满 时 ，LruCache 会 移 除 较 早 使 用 的 缓存 对 象 ， 
然后 再 添加 新 的 缓存 对 象 。 这 里 读者 要 明白 强 引 用 、 软 引用 和 弱 引 用 
的 区 别 ， 如 下 所 示 。 


。 强 引用 : 直接 的 对 象 引用 | 

。 软 引用 : 当 一 个 对 象 只 有 软 引 用 存在 时 ， 系 统 内 存 不 足 时 此 对 象 
会 被 gc 回收 ; 

BoA: 当 一 个 对 象 只 有 弱 引 用 存在 时 ， 此 对 象 会 随时 被 gc 回 
收 。 


男 外 LruCache 是 线程 安全 的 ， 下 面 症 LruCache 的 定义 : 
public class LruCache<K,V> { 


private final LinkedHashMap<K,V> map; 


} 


LruCache 的 实现 比较 简单 ， 读 者 可 以 参考 它 的 源码 ， 这 里 仅 介 绍 
如 何 使 用 LruCache 来 实现 内 存 缓 存 。 仍 然 拿 图 片 缓存 玉 举例 子 ， 下 面 
的 代码 展示 了 LruCache 的 典型 的 初始 化 过 程 : 


int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 
1024); 


int cacheSize = maxMemory / 8; 


mMemoryCache = new LruCache<String,Bitmap>(cacheSize) { 
@Override 
protected int sizeOf(String key,Bitmap bitmap) { 
return bitmap.getRowBytes() * 
bitmap.getHeight() / 1024; 
} 
}; 


在 上 面 的 代码 中 ， 只 需要 提供 缓存 的 总 容量 大 小 并 重 写 sizeOf 方 
法 即 可 。sizeOf 方 法 的 作用 是 计算 缓存 对 象 的 大 小 ， 这 里 大 小 的 单位 
需要 和 总 容量 的 单位 一 致 。 对 于 上 面 的 示例 代码 来 说 ， 总 容量 的 大 小 
为 当前 进程 的 可 用 内 存 的 8， 单位 为 KB， 而 sizeOf 方 法 则 完成 了 
Bitmap 对 和 象 的 大 小 计算 。 很 明显 ， 之 所 以 除 以 1024 也 是 为 了 将 其 单位 
转换 为 KB。 一 些 特殊 情况 下 ， 还 需要 重 写 LruCache 的 entryRemoved 方 
法 ，LruCache 移 除 旧 缓存 时 会 调用 entryRemoved 方 法 ， 因 此 可 以 在 
entryRemoved 中 完成 一 些 资 源 回收 工作 (如 果 需 要 的 话 ) > 


除了 LruCache 的 创建 以 外 ， 还 有 缓存 的 获取 和 添加 ， 这 也 很 简 
单 ， 从 LruCache 中 获取 一 个 缓存 对 象 ， 如 下 所 示 。 


mMemoryCache.get(key) 
向 LruCache 中 添加 一 个 缓存 对 象 ， 如 下 所 示 。 
mMemoryCache.put(key, bitmap) 


LruCache 还 支持 删除 操作 ， 通 过 remove 方 法 即 可 删除 一 个 指定 的 
缓存 对 象 。 可 以 看 到 LruCache 的 实现 以 及 使 用 都 非常 人 简单， 虽然 人 简 


单 ， 但 是 仍然 不 影响 它 上 具有 强大 的 功能 ， 从 Android 3.1 开 始 ， 
LruCache 就 已 经 是 Android 源 码 的 一 部 分 了 。 


12.2.2 DiskLruCache 


DiskLruCache 用 于 实现 存储 设备 缓存 ， 即 磁 强 缓存 ， 它 通过 将 组 
存 对 象 写 入 文件 系统 从 而 实现 缓存 的 效果 。DiskLruCache 得 到 了 
Android 官 方 文档 的 推荐 ， 但 它 不 属于 Android SDK 的 一 部 分 ， 它 的 源 
码 可 以 从 如 下 网 址 得 到 : 


https://android.googlesource.com/platform/libcore/+/android- 


4.1.1_r1/1luni/src/main/java/libcore/io/DiskLruCache. java 


需要 注意 的 是 ， 从 上 述 网 址 获取 的 DiskLruCache 的 源码 并 不 能 
接 在 Android 中 使 用 ， 需 要 稍微 修改 编译 错误 。 下 面 分 别 从 
DiskLruCache 的 创建 、 缓 存 查找 和 缓存 添加 这 三 个 方面 来 介绍 
DiskLruCache 的 使 用 方式 。 


1. DiskLruCache 的 创建 


DiskLruCache 并 不 能 通过 构造 方法 来 创建 ， 它 提供 了 open 方 法 用 
于 创建 自嘲 ， 如 下 所 示 。 


public static DiskLruCache open(File directory,int 


appVersion,int valueCount,long maxSize) 


opn AUTSA, HAB SRAM ARANA, 
中 的 存储 路 径 。 缓 存 路 径 可 以 选择 SD 卡 上 的 缓存 目 孙 ， 有 具体 是 
指 /sdcard/Android/data/package_name/cache 目 未 ， 其 中 package_name 表 
示 当 前 应 用 的 包 名 ， 当 应 用 被 凶 载 后 ， 此 目录 会 一 并 说 删除 。 当 然 也 
可 以 选择 SD 卡 上 的 其 他 指定 目录 ， 还 可 以 选择 data 下 的 当前 应 用 的 目 
录 ， 有 具体 可 根据 需要 灵活 设 定 。 这 里 给 出 一 个 建议 : 如果 应 用 印 载 后 
就 希望 删除 缓存 文件 ， 那 么 就 选择 SD 卡 上 的 缓存 目录 ， 如 有 果 希 望 保留 
绥 存 数据 那 束 应 该 选择 SD 卡 上 的 其 他 特定 目录 。 


第 二 个 参数 表示 应 用 的 版 本 号 ， 一 般 设 为 1 即 可 。 当 版 本 号 发 生 改 
变 时 DiskLruCache 会 清空 之 前 所 有 的 缓存 文件 ， 而 这 个 特性 在 实际 开 
发 中 作用 并 不 大 ， 很 多 情况 下 即使 应 用 的 版 本 号 发 生 了 改变 缓存 文件 
却 仍然 是 有 效 的 ， 因 此 这 个 参数 设 为 1 比较 好 。 


第 三 个 参数 表示 单个 节点 所 对 应 的 数据 的 个 数 ， 一 般 设 为 1 即 可 。 
第 四 个 参数 表示 缓存 的 总 大 小 ， 比 如 50MB ， 当 缓存 大 小 超出 这 个 设 
定 值 后 ，DiskLruCache 会 清除 一 些 缓存 从 而 保证 总 大 小 不 大 于 这 个 设 
定 值 。 下 面 是 一 个 典型 的 DiskLruCache 的 创建 过 程 : 


private static final long DISK CACHE SIZE = 1024 * 1024 * 
50; //50MB 

File diskCacheDir = getDiskCacheDir (mContext, "bitmap"); 

if (!diskCacheDir.exists()) { 


diskCacheDir.mkdirs(); 


mDiskLruCache = 


DiskLruCache.open(diskCacheDir,1,1,DISK_CACHE_SIZE); 


2. DiskLruCache 的 缓存 添加 


DiskLruCache 的 N 的 操作 是 通过 Editor 完 成 的 ，Editor 表 示 
一 个 缓存 对 象 的 编辑 对 象 。 这 里 仍然 以 图 片 缓存 举例 ， 痢 先 需 要 获取 
图 片 岂 所 对 应 的 key， 然 后 根据 key 就 可 以 通过 edit0 来 获取 Editor 对 
象 ， 如 采 这 个 缓存 正在 被 编辑 ， 那么 edit0 会 返回 nul ， 即 
DiskLruCache 不 允许 同时 编辑 一 个 缓存 对 象 。 之 所 以 要 把 由 转换 成 
key， 是 因为 图 片 的 url 中 很 可 能 有 特殊 字符 ， 这 将 影响 url 在 Android 中 
直接 使 用 ， 一 般 采 用 url 的 md5 值 作为 key， 如 下 所 示 。 


private String hashKeyFormUrl(String url) { 
String cachekey; 
try { 
final MessageDigest mDigest = 
MessageDigest.getInstance("MD5"); 
mDigest.update(url.getBytes()); 
cachekey = bytesToHexString(mDigest.digest()); 
} catch (NoSuchAlgorithmException e) { 
cachekey = String.value0f (url.hashCode()); 
} 


return cacheKey; 
} 
private String bytesToHexString(byte[] bytes) { 
StringBuilder sb = new StringBuilder(); 
for (int i = 0; i < bytes.length; i++) { 
String hex = Integer.toHexString(OxFF € 
bytes[i]); 


if (hex.length() == 1) { 
sb.append('0'); 
J 
sb.append(hex); 
J 


return sb.toString(); 


将 图 片 的 unl 转 成 key 以 后 ， 束 可 以 获取 Editor 对 象 了 。 对 于 这 个 key 
来 说 ， 如 果 当 前 不 存在 其 他 Editor 对 象 ， 那 么 edit0 就 会 返回 一 个 新 的 
Editor 对 象 ， 通 过 它 束 可 以 得 到 一 个 文件 输出 流 。 需 要 注意 的 是 ， 由 于 
前 面 在 DiskLruCache 的 open 方 法 中 设置 了 一 个 节点 只 能 有 一 个 数据 ， 
因此 下 面 的 DISK_CACHE_INDEX 常 量 直接 设 为 0 即 可 ， 如 下 所 示 。 


String key = hashKeyFormUrl(url); 
DiskLruCache.Editor editor = mDiskLruCache.edit(key); 
if (editor != null) { 
OutputStream outputStream = 


editor .newOutputStream(DISK_CACHE_INDEX) ; 
J 


有 了 文件 输出 流 ， 接 下 来 要 怎么 做 呢 ? 其 实 是 这 样 的 ， 当 从 网 络 
下 载 图片 时 ， 图 片 束 可 以 通过 这 个 文件 输出 流 写 入 到 文件 系统 上 ， 这 
个 过 程 的 实现 如 下 所 示 。 


public boolean downloadUrlToStream(String urlString, 
OutputStream outputStream) { 


HttpURLConnection urlConnection = null; 


经 过 上 面 的 步 又 ， 其 实 并 没有 真正 地 将 图 片 写 入 文件 系统 ， 还 必 
EN Editor commit) RHEE APE, WRR FRIERE T 
那么 还 可 以 通过 Pditor 的 abort(0) 来 回 退 整个 操作 ， 这 个 过 程 如 下 所 
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OutputStream outputStream 
editor .newOutputStream(DISK_CACHE_INDEX) ; 
if (downloadUrlToStream(url,outputStream)) { 
editor.commit(); 
} else { 
editor.abort(); 


} 
mDiskLruCache.flush(); 


经 过 上 面 的 几 个 步 又， 图 片 已 经 被 正确 地 写 入 到 文件 系统 了 ， 接 
下 来 图 片 获 取 的 操作 束 不 需要 请 求 网 络 了 。 


3. DiskLruCache 的 缓存 查找 


和 缓存 的 添加 过 程 类 似 ， 缓 存 查 找 过 程 也 需要 将 unl 转换 为 key， 
然后 通过 DiskLruCache 的 get 方 法 得 到 一 个 Snapshot 对 象 ， 接 着 再 通过 
Snapshot 对 象 即 可 得 到 缓存 的 文件 输入 流 ， 有 了 文件 输出 沪 ， 目 然 驶 
可 以 得 到 Bitmap 对 象 了 。 为 了 避免 加 载 图 乒 过 程 中 导致 的 OOM 问 题 ， 
一 般 不 建议 直接 加 载 原 始 图 片 。 在 第 12.1 和 中 已 经 介绍 了 通过 
BitmapFactory.Options 对 象 来 加 载 一 张 缩放 后 的 图 片 ， 但 是 那 种 方法 对 
FileInputStream 的 缩放 存在 问题 ， 原 因 是 FileInputStream 是 一 种 有 序 的 
文件 流 ， 而 两 次 decodeStream 调 用 影响 了 文件 流 的 位 置 属性 ， 导 致 了 
第 二 次 decodeStream 时 得 到 的 是 null。 为 了 解决 这 个 问题 ， 可 以 通过 文 


件 流 来 得 到 它 所 对 应 的 文件 描述 符 ， 然 后 再 通过 
BitmapFactory.decodeFileDescriptor 方 法 来 加 载 一 张 缩 放 后 的 图 片 ， 这 
个 过 程 的 实现 如 下 所 示 。 


Bitmap bitmap = null; 
String key = hashKeyFormUrl(url); 
DiskLruCache.Snapshot snapShot = mDiskLruCache.get(key); 
if (snapShot != null) { 
FileInputStream fileInputStream = 
(FileInputStream)snapShot..getInput- 
Stream(DISK_CACHE_INDEX); 
FileDescriptor fileDescriptor = 
fileInputStream.getFD(); 
bitmap = 
mImageResizer .decodeSampledBitmapFromFileDescriptor 
(fileDescriptor, 
reqwidth, reqHeight); 
if (bitmap != null) { 
addBitmapToMemoryCache(key, bitmap) ; 


上 面 介 绍 了 DiskLruCache 的 创建 、 绥 存 的 添加 和 查找 过 程 ， 读 者 
应 该 对 DiskLruCache 的 使 用 方式 有 了 一 个 大 致 的 了 解 ， 除 此 之 外 ， 
DiskLruCache 还 提供 了 remove、delete 等 方法 用 于 磁盘 缓存 的 删除 操 
作 。 关 于 DiskLruCache 的 内 部 实现 这 里 束 不 再 介绍 了 ， 读 者 感 兴趣 的 
话 可 以 查看 它 的 源码 实现 。 


12.2.3 ImageLoader 的 实现 


在 本 章 的 前 面 先后 介绍 了 Bitmap 的 高 效 加 载 方式 、LruCache 以 及 
DiskLruCache， 现 在 我 们 来 着 手 实现 一 个 优秀 的 ImageLoader 。 


般 来 说 ， 一 个 优秀 的 ImageLoader 应 该 具备 如 下 功能 : 


图 片 的 同步 加 载 ; 
图 片 的 异步 加 载 ; 
图 片 压缩 ; 

内 存 缓存 ; 

做 盘 缓存 : 

网 络 拉 取 。 


图 片 的 同步 加 载 是 指 能 够 以 同步 的 方式 回调 用 者 提供 所 加 载 的 图 
片 ， 这 个 图 片 可 能 是 从 内 存 缓存 中 读 取 的 ， 也 可 能 是 从 磁盘 缓存 中 读 
取 的 ， 还 可 能 是 从 网 络 拉 取 的 。 图 片 的 异步 加 载 是 一 个 很 有 用 的 功 
能 ， 很 多 时 候 调用 者 不 想 在 单独 的 线程 中 以 同步 的 方式 来 获取 图 片 ， 
这 个 时 候 ImageLoader 内 部 需要 目 己 在 线程 中 加 载 图 片 并 将 图 片 设 置 给 
所 需 的 ImageView。 图 片 压缩 的 作用 更 毋 良 置 颖 了 ， 这 十 降 低 OOM 概 
率 的 有 效 手 段 ，ImageLoader 必 须 合 适 地 处 理 图 片 的 压缩 问题 。 


内 存 缓存 和 磁盘 缓存 是 ImageLoader 的 核心 ， 也 是 ImageLoader 的 
意义 之 所 在 ， 通 过 这 两 级 缓存 极 大 地 提高 了 程序 的 效率 并 且 有 效 地 降 
低 了 对 用 户 所 造成 的 流量 消耗 ， 只 有 当 这 两 级 缓存 都 不 可 用 时 才 需 要 
从 网 络 中 拉 取 图 厂 。 


除 此 之 外 ，ImageLoader 还 需要 处理 一 些 特殊 的 情况 ， 比 如 在 
ListView 或 者 GridView 中 ，View 复 用 既是 它们 的 优点 也 是 它们 的 缺 
点 ， 优 点 想必 读者 都 很 清楚 了 ， 那 缺点 可 能 还 不 太 清 楚 。 考 虑 一 种 情 
况 ， 在 ListView 或 者 GridView 中 ， 假 设 一 个 item A 正在 从 网 络 加 载 图 
片 ， 它 对 应 的 ImageView 为 A， 这 个 时 候 用 户 快速 问 下 请 动 列 表 ， 很 可 
能 item B 复 用 了 ImageView A， 然 后 等 了 一 会 之 前 的 图 片 下 载 完 毕 了 
如 果 和 直接 给 ImageView A 设置 图 片 ， 由 于 这 个 时 候 ImageView A 被 item 
B 所 复 用 ， 但 是 item B 要 显示 的 图 片 显 然 不 是 item A 刚刚 下 载 好 的 图 
厂 ， 这 个 时 候 束 会 出 现 item B 中 显示 了 item A 的 图 片 ， 这 就 是 常见 的 列 
表 的 错位 问题 ，ImageLoader 需 要 正确 地 处理 这 些 特殊 情况 。 


上 面 对 ImageLoader 的 功能 做 了 一 个 全 面 的 分 析 ， 下 面 束 可 以 一 
步 实现 一 个 ImageLoader 了 ， 这 里 主要 分 为 如 下 几 步 。 


1. 图 片 压 缩 功 能 的 实现 


图 片 压缩 在 第 12.1 市 中 已 经 做 了 介绍 ， 这 里 束 不 再 多 说 了 ,为 了 
有 民 好 的 设计 风格 ， 这 里 单独 抽象 了 一 个 类 用 于 完成 图 片 的 压缩 功 
能 ， 这 个 类 叫 JmageResizer， 它 的 实现 如 下 所 示 。 


public class ImageResizer { 
private static final String TAG = "ImageResizer"; 
public ImageResizer() { 
} 
public Bitmap 
decodeSampledBitmapFromResource(Resources res, 
int resId,int reqwidth,int reqHeight) { 


// First decode with inJustDecodeBounds=true to 


check dimensions 
final BitmapFactory.Options options = new 
BitmapFactory.Options(); 
options.inJustDecodeBounds = true; 
BitmapFactory.decodeResource(res, resId, options); 
// Calculate inSampleSize 
options.inSampleSize = 
calculateInSampleSize(options, reqwidth, reqHeight ) ; 
// Decode bitmap with inSampleSize set 
options.inJustDecodeBounds = false; 
return 
BitmapFactory.decodeResource(res, resid, options); 
di 
public Bitmap 
decodeSampledBitmapFromFileDescriptor(FileDescriptor fd, 
int reqwidth, int reqHeight) { 
// First decode with inJustDecodeBounds=true to 
check dimensions 
final BitmapFactory.Options options = new 
BitmapFactory.Options(); 


options.inJustDecodeBounds = true; 


BitmapFactory.decodeFileDescriptor(fd, null, options); 
// Calculate inSampleSize 
options.inSampleSize = 
calculateInSampleSize(options, reqwidth, reqHeight ); 


// Decode bitmap with inSampleSize set 


2. 内 存 缓存 和 磁盘 缓存 的 实现 


这 里 选择 LruCache 和 DiskLruCache 来 分 别 完 成 内 存 缓存 和 侯 盘 绥 
存 的 工作 。 在 ImageLoader 初 始 化 时 ， 会 创建 LruCache 和 
DiskLruCache， 如 下 所 示 。 


TUNEAR, MEMOS AA, EA A a aR ZS E 
小 于 磁盘 缓存 所 需 的 大 小 ， 一 般 是 指 用 户 的 手机 空间 已 经 不 足 了 ， 因 
此 没有 办 法 创建 磁盘 缓存 ， 这 个 时 候 人 磁盘 缓存 束 会 失效 。 在 上 面 的 代 
码 实现 中 ，ImageLoader 的 内 存 缓存 的 容量 为 当前 进程 可 用 内 存 的 
1/8, MAREA EA OMB ° 


内 存 缓存 和 磁盘 缓存 创建 完毕 后 ， 还 需要 提供 方法 来 完成 缓存 的 
添加 和 获取 功能 。 首 和 完 看 内 存 缓存 ， 它 的 添加 和 读 取 过 程 比较 简单 ， 
如 下 所 示 。 


private void addBitmapToMemoryCache(String key,Bitmap 
bitmap) { 
if (getBitmapFromMemCache(key) == null) { 
mMemoryCache.put(key, bitmap); 


} 
private Bitmap getBitmapFromMemCache(String key) { 


return mMemoryCache.get(key); 


M e n 些 ， 具 体内 容 已 经 在 
12.2.2 节 中 进行 了 详细 的 介绍 ， 这 里 再 简单 说 明 一 下 。 磁盘 缓存 的 添加 
需要 通过 Editor 来 完成 ，Editor 提 供 了 commit 和 abort 方 法 来 提交 和 撤销 
对 文件 系统 的 写 操作 ， di 体 实现 请 参看 下 面 的 loadBitmap-FromHttp 方 
法 。 磁 盘 绥 存 的 读 取 需要 通过 Snapshot 来 完成 ， 通 过 Snapshot 可 以 得 到 
似 盘 缓存 对 象 对 应 的 FileInputStream， 但 是 FileInputStream 无 法 便捷 地 
进行 压缩 ， 所 以 通过 FileDescriptor 来 加 载 压缩 后 的 图 片 ， 最 后 将 加 载 
后 的 Bitmap 添加 到 内 存 缓 存 中 ， 上 具体 实 现 请 参看 下 面 的 
loadBitmapFromDiskCache 方 法 。 


private Bitmap loadBitmapFromHttp(String url,int 
reqwidth, int reqHeight ) 
throws IOException { 
if (Looper.myLooper() == Looper.getMainLooper()) { 
throw new RuntimeException("can not visit 


network from UI Thread."); 
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3. 同步 加 载 和 异步 加 载 接口 的 设计 


首先 看 同步 加 载 ， 同 步 加 载 接口 需要 外 部 在 线程 中 调用 ， 这 是 因 
为 同步 加 载 很 可 能 比较 耗 时 ， 它 的 实现 如 下 所 示 。 


created."); 
bitmap = downloadBitmapFromUrl(uri); 


A 


return bitmap; 


从 loadBitmap 的 实现 可 以 看 出 ， 其 工作 过 程 遵循 如 下 几 步 : HA 
尝试 从 内 存 缓存 中 读 取 图 片 ， 接 着 尝试 从 磁 僵 缓存 中 读 取 网 片 ， 最 后 
才 从 网 络 中 拉 取 图 片 。 另 外 ， 这 个 方法 不 能 在 主线 程 中 调用 ， 否 则 残 
抛 出 异常 。 这 个 执行 环境 的 检查 是 在 loadBitmapFromHttp 中 实现 的 ， 
通过 检查 当前 线程 的 Looper 是 否 为 主线 程 的 Looper 来 判断 当前 线程 是 
否 是 主线 程 ， 如 有 果 不 是 主线 程 陇 直接 抛 出 异常 中 止 程序 ， 如 下 所 示 。 


if (Looper.myLooper() == Looper.getMainLooper()) { 
throw new RuntimeException("can not visit network from 
UI Thread."); 
} 


接着 看 异步 加 载 接 口 的 设计 ， 如 下 所 示 。 


public void bindBitmap(final String uri,final ImageView 
imageView, 
final int reqwidth,final int reqHeight) { 
imageView.setTag(TAG_KEY_URI, uri); 
Bitmap bitmap = loadBitmapFromMemCache(uri); 
if (bitmap != null) { 
imageView.setImageBitmap(bitmap); 


return; 


从 bindBitmap 的 实现 来 看 ，bindBitmap 方 法 会 党 试 从 内 存 缓存 中 读 
取 图 片 ， 如 果 读 取 成 功 就 直接 返回 结果 ， 否 则 会 在 线程 池 中 去 调用 
loadBitmap 方 法 ， 当 图 片 加 载 成 功 后 再 将 图 片 、 图 片 的 地 址 以 及 需要 
绑 定 的 imageView 封装 成 一 个 LoaderResult 对 象 ， 然 后 再 通过 
mMainHandler 回 主线 程 发 送 一 个 消息 ， 这 样 束 可 以 在 主线 程 中 给 
imageView 设 置 图 片 了 ， 之 所 以 通过 Handler 来 中 转 是 因为 子 线程 无 法 
访问 UI。 


bindBitmap 中 用 到 了 线程 池 和 Handler， 这 里 看 一 下 它们 的 实现 ， 
首先 看 线程 池 THREAD_POOL_EXECUTOR 的 实现 ， 如 下 所 示 。 可 以 
看 出 它 的 核心 线程 数 为 当前 设备 的 CPU 核心 数 加 1， 最 大 容量 为 CPU 核 
心 数 的 2 倍加 1， 线 程 用 置 超时 时 长 为 10 秒 ， 关 于 线程 池 的 详细 介绍 可 
以 参看 第 11 章 的 有 关内 容 。 


private static final int CORE_POOL_SIZE = CPU_COUNT + 1; 
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 
les 
private static final long KEEP_ALIVE = 10L; 
private static final ThreadFactory sThreadFactory = new 
ThreadFactory() { 
private final AtomicInteger mCount = new 
AtomicInteger (1); 
public Thread newThread(Runnable r) { 
return new Thread(r,"ImageLoader#" + 
mCount .getAndIncrement()); 
} 
y; 
public static final Executor THREAD_POOL_EXECUTOR = new 
ThreadPoolExecutor ( 
CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, 
KEEP_ALIVE, TimeUnit.SECONDS, 
new LinkedBlockingQueue<Runnable> 


(),sThreadFactory); 


之 所 以 采用 线程 池 是 有 原因 的 ， 首 先 肯定 不 能 采用 普通 的 线程 去 
做 这 个 事 ， 线 程 池 的 好 处 在 第 11 章 已 经 做 了 详细 的 说 明 。 如 有 果 和 直接 采 
用 普通 的 线程 去 加 载 图 片 ， 随 着 列表 的 滑动 这 可 能 会 产生 大 量 的 线 
程 ， 这 样 并 不 利于 整体 效率 的 提升 。 另 外 一 点 ， 这 里 也 没有 选择 采用 
AsyncTask，AsyncTask 封 装 了 线程 池 和 Handler ， 按 道理 它 应 该 适合 
ImageLoader 的 场景 。 从 第 11 章 中 对 AsyncTask 的 分 析 可 以 知道 ， 
AsyncTask 在 3.0 的 低 版 本 和 高 版 本 上 具有 不 同 的 表现 ， 在 3.0 以 上 的 版 
本 AsyncTask 无 法 实现 并 发 的 效果 ， 这 显然 是 不 能 接受 的 ， 因 为 
ImageLoader 就 是 需要 并 发 特性 ， 虽 然 可 以 通过 改造 AsyncTask 或 者 使 
用 AsyncTask 的 executeOnExecutor 方 法 的 形式 来 执行 异步 任务 ， 但 是 这 
终归 是 不 太 上 自然 的 实现 方式 。 鉴 于 以 上 两 点 原因 ， 这 里 选择 线程 池 和 
Handler 来 提供 ImageLoader 的 并 发 能 力 和 访问 UI 的 能 力 。 


分 析 完 线程 池 的 选择 ， 下 面 看 一 下 Handler 的 实现 ， 如 下 所 示 。 
ImageLoader 和 直接 采用 主线 程 的 Looper 来 构造 Handler 对 象 ， 这 了 束 使 得 
ImageLoader 可 以 在 非 主 线程 中 构造 了 。 男 外 为 了 解决 由 于 View 复 用 所 
导致 的 列表 错位 这 一 问题 ， 在 给 ImageView 设 置 图 片 之 前 都 会 检查 它 
的 url 有 没有 发 生 改 变 ， 如 果 发 生 改 变 束 不 再 给 它 设置 图 片 ， 这 样 就 解 
决 了 列表 错位 的 问题 。 


private Handler mMainHandler = new 
Handler (Looper .getMainLooper()) { 
@Override 
public void handleMessage (Message msg) { 
LoaderResult result = (LoaderResult) msg.obj; 
ImageView imageView = result.imageView; 


imageView.setImageBitmap(result.bitmap); 


到 此 为 止 ，ImageLoader 的 细 方 都 已 经 做 了 全 面 的 分 析 ， 下 面 是 
ImageLoader 的 完整 的 代码 。 


private static final long DISK_CACHE_SIZE = 1024 * 
1024 * 50; 
private static final int IO_BUFFER_SIZE = 8 * 1024; 
private static final int DISK_CACHE_INDEX = 0; 
private boolean mIsDiskLruCacheCreated = false; 
private static final ThreadFactory sThreadFactory = 
new ThreadFactory() { 
private final AtomicInteger mCount = new 
AtomicInteger (1); 
public Thread newThread(Runnable r) { 
return new Thread(r, "ImageLoader#" + 
mCount .getAndIncrement()); 
上 
y; 
public static final Executor THREAD_POOL_EXECUTOR = 
new ThreadPool - 
Executor ( 
CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, 
KEEP_ALIVE, TimeUnit.SECONDS, 
new LinkedBlockingQueue<Runnable> 
(),sThreadFactory); 
private Handler mMainHandler = new 
Handler (Looper .getMainLooper()) { 
@Override 
public void handleMessage (Message msg) { 
LoaderResult result = (LoaderResult) msg.obj; 


ImageView imageView = result.imageView; 


VERSION_CODES.GINGERBREAD) { 
return path.getUsableSpace(); 
} 
final StatFs stats = new StatFs(path.getPath()); 
return (long) stats.getBlockSize() * (long) 
stats.getAvailableBlocks(); 
} 
private static class LoaderResult { 
public ImageView imageView; 
public String uri; 
public Bitmap bitmap; 
public LoaderResult(ImageView imageView, String 
uri,Bitmap bitmap) { 
this.imageView = imageView; 
this.uri = uri; 


this.bitmap = bitmap; 


12.3 ImageLoader 的 使 用 


在 12.2.3 世 中 我 们 实现 了 一 个 功能 完整 的 InageLoader， 丁 将 演 
示 如 何 通 过 Image-Loader 来 实现 一 个 照片 墙 的 效果 ， 实 际 上 我 们 会 发 
现 ， 通 过 ImageLoader 打 造 一 个 照 厂 墙 是 轻而易举 的 事情 。 最 后 针对 如 


何 提高 列表 的 滑动 流畅 度 这 个 问题 ， 本 节 会 给 出 一 些 针对 性 的 建议 供 
读者 参考 。 


12.3.1 RAER 


实现 照片 墙 效果 需要 用 到 GridView， 下 面 先 准备 好 GridView 所 需 
的 布局 文件 以 及 item 的 布局 文件 ， 如 下 所 示 。 


// Gridview 的 布局 文件 
<LinearLayout 
xmins:android="http://schemas.android.com/apk/res/android" 
xmins:tools="http://schemas.android.com/tools" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: orientation="vertical" 
android: padding="5dp" > 
<GridView 
android: id="@t+id/gridView1" 
android: Layout_width="match_parent" 
android: Layout_height="match_parent" 
android: gravity="center" 
android: horizontalSpacing="5dp" 
android: verticalSpacing="5dp" 
android: listSelector="@android:color/transparent" 
android:numColumns="3" 


android: stretchMode="columnwidth" > 


</GridView> 
</LinearLayout> 
// Gridview 的 Item 的 布局 文件 
<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmins:android="http://schemas.android.com/apk/res/android" 
android: Layout_width="match_parent" 
android: Llayout_height="wrap_content" 
android: gravity="center" 
android:orientation="vertical" > 
<com.ryg.chapter_12.ui.SquareImageView 
android: id="@+id/image" 
android: Layout_width="match_parent" 
android: Layout_height="wrap_content" 
android: scaleType="centerCrop" 
android: src="@drawable/image_default" /> 


</LinearLayout> 


也 许 读者 已 经 注意 到 ，GridView 的 item 的 布局 文件 中 并 没有 采用 
ImageView， 而 是 采用 了 一 个 叫 SquareImageView 的 目 定 义 控件 。 顾 名 
思 义 ， 它 的 作用 就 是 打造 一 个 正方 形 的 ImageView， 这 样 整个 照片 墙 
看 起 来 会 比较 整齐 美观 。 要 实现 一 个 蜗 、 高 相等 的 ImageView 是 非常 
简单 的 一 件 事 ， 只 需要 在 它 的 onMeasure 方 法 中 稍微 做 一 下 处 理 ， 如 下 
所 示 。 


public class SquareImageView extends ImageView { 


public SquareImageView(Context context) { 


可 以 看 出 ， 我 们 在 SquareImageView 的 onMeasure 方 法 中 很 巧妙 地 
将 heightMeasureSpec 替 换 为 widthMeasureSpec， 这 样 什 么 都 不 用 做 了 驶 
可 以 一 个 宽 、 高 相等 的 ImagevView 了 “。 关 于 View 的 测量 等 过 程 的 介 


绍 ， 请 读者 参看 第 4 章 的 有 关内 容 ， 这 里 不 再 痪 述 了 。 


接着 需要 实现 一 个 BaseAdapter 给 GridView 使 用 ， 下 面 的 代码 展示 
了 ImageAdapter 的 实现 细节 ， 其 中 mUrList 中 存储 的 是 图 片 的 url: 


ImageView imageView = holder.imageView; 
final String tag = (String)imageView.getTag(); 
final String uri = getItem(position); 


if (!uri.equals(tag)) { 


imageView.setImageDrawable(mDefaultBitmapDrawable); 
} 
if (mIsGridViewIdle && 
mCanGetBitmapFromNetWork) { 


imageView.setTag(uri); 


mImageLoader .bindBitmap(uri, imageView, mImagewWidth, mImage - 
width); 
} 


return convertView; 


从 上 述 代 码 来 看 ，ImageAdapter 的 实现 过 程 非 常 简 捷 ， 这 几乎 是 
最 简洁 的 BaseAdapter 的 实现 了 。 但 是 位 洛 并 不 等 于 位 单 ，getView 方 法 
中 核 D R W 内 A 二 .各 请 a wm mos 
mImageLoader.bindBitmap(uri,image View,mImageWidth,mImageWidth) ° 
通过 bindBitmap 方 法 很 轻松 地 将 复杂 的 图 片 加 载 过 程 交 给 了 
ImageLoader ， ImageLoader 加载 图 片 以 后 会 把 图 片上 自动 设置 给 
imageView, NETTE, BHENFRF ` RRT AN BA EEE 
工作 过 程 对 ImageAdapter 来 说 都 是 透明 的 。 在 这 种 设计 思想 下 ， 


ImageAdapter 什 么 也 不 需要 知道 ， 因 此 这 是 一 个 极其 轻 量 级 的 
ImageAdapter ° 


接着 将 ImageAdapter 设 置 给 GridView， 如 下 所 示 。 到 此 为 止 一 个 
绚丽 的 图 片 墙 就 大 功 告 成 了 ， 是 不 是 惊叹 于 如 此 简捷 而 又 优美 的 实现 
过 程 呢 ? 


mImageGridView = (GridView) findViewById(R.id.gridView1); 
mImageAdapter = new ImageAdapter(this); 


mImageGridView.setAdapter (mImageAdapter); 


最 后 ， 看 一 下 我 们 亲手 打造 的 图 片 墙 的 效果 图 ， 如 图 12-1 所 示 。 
征 不 是 看 起 来 很 优美 呢 ? 
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图 12-1 采用 ImageLoader 实 现 的 照片 墙 


另外 ， 本 节 中 的 照片 墙 应 用 首次 运行 时 会 从 网 络 中 加 载 大 量 图 
片 ， 这 会 消耗 若干 MB 的 流量 ， 因 此 建议 首次 运行 时 选择 WiFi 环 境 ， 
同时 程序 启动 时 也 会 有 相应 的 提示 ， 在 非 WiFi 环 境 下 ， 打 开 应 用 时 会 
弹出 如 下 提示 ， 请 读者 运行 时 注意 一 下 ， 避 免 消 耗 过 多 的 流量 。 


if (!mIswifi) { 
AlertDialog. Builder builder = new 
AlertDialog.Builder(this); 
builder .setMessage(" 初 次 使 用 会 从 网 络 中 下 载 大 概 5MB 的 图 片 ， 确 认 
要 下 载 吗 ?")， 
builder .setTitle(" 注 意 "); 


builder.setPositiveButton("7",new OnClickListener() { 


@Override 
public void onClick(DialogInterface dialog, int 
which) { 
mCanGetBitmapFromNetWork = true; 


mImageAdapter.notifyDataSetChanged(); 


1); 
builder.setNegativeButton("®",null); 


builder.show(); 


12.3.2 ”优化 列表 的 卡 顿 现象 


这 个 问题 困扰 了 很 多 开发 者 ， 其 实 答案 很 商 单 ， 不 要 在 主线 程 中 
做 太 耗 时 的 操作 即 可 提高 清 动 的 流畅 度 ， 可 以 从 三 个 方面 来 说 明 这 个 


问题 。 


首先 ， 不 要 在 getView 中 执行 耗 时 操作 。 对 于 上 面 的 例子 来 说 ， 如 
果 直 接 在 getView 方 法 中 加 载 图 片 ， 肯 定 会 导致 卡 顿 ， 因 为 加 载 图 片 是 
一 个 耗 时 的 操作 ， 这 种 操作 必须 通过 异步 的 方式 来 处 理 ， 束 像 
ImageLoader 实 现 的 那样 。 


其 次 ， 控 制 异 步 任务 的 执行 频率 。 这 一 点 也 很 重要 ， 对 于 列表 来 
说 ， 仅 仅 在 getView 中 采用 异步 操作 是 不 够 的 。 考 虑 一 种 情况 ， 以 照 放 
间 来 说 ， 在 getView 方 法 中 会 通过 ImageLoader 的 bindBitmap 方 法 来 异步 
加 载 图 乒 ， 但 是 如 果 用 户 刻 意 地 频 党 上 下 请 动 ， 这 吏 会 在 一 瞬间 产生 
上 百 个 异步 任务 ， 这 些 异 步 任务 会 造成 线程 池 的 拥堵 并 随即 融 来 大 量 
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何 解决 这 个 问题 呢 ? 可 以 考虑 在 列表 滑动 的 时 候 停 止 加 载 图 片 ， 尽 管 
这 个 过 程 是 异步 的 ， 等 列表 停 下 来 以 后 再 加 载 图 片 仍然 可 以 获得 民 好 
的 用 户 体验 。 具 体 实 现时 ， 可 以 给 ListView 或 者 GridView 设 置 
setOnScrollListener, ， 并 在 OnScrollListener 的 onScrollStateChanged 方 法 
中 判断 列表 是 否 处 于 请 动 状 态 ， 如 采 是 的 话 驶 停止 加 载 图 乒 ， 如 下 所 
To 


public void onScrollStateChanged(AbsListView view, int 
scrollState) { 
if (scrollState == OnScrollListener .SCROLL_STATE_IDLE) 


mIsGridViewIdle = true; 
mImageAdapter.notifyDataSetChanged(); 
} else { 


mIsGridViewIdle = false; 


} 


然后 在 getView 方 法 中 ， 仅 当 列表 静止 时 才能 加 载 图 乒 ， 如 下 所 
ZR œ 


if (mIsGridViewIdle && mCanGetBitmapFromNetWork) { 


imageView.setTag(uri); 


mImageLoader .bindBitmap(uri, imageView, mImagewidth, mImagewidth); 


} 


RU, HUELMA, WRARAS ARA, HERE 
某 些 特殊 情况 下 ， 列 表 还 是 会 有 偶尔 的 卡 顿 现象 ， 这 个 时 候 还 可 以 开 
启 人 硬件 加 速 。 绝 大 多 数 情况 下 ， 硬 件 加 速 都 可 以 解决 莫名 的 卡 顿 问 
题 ， 通 过 设置 android:hardwareAccelerated="true" 即 可 为 Activity 开 局 硬 
件 加 速 。 


第 13 章 ”综合 技术 


本 章 介 绍 的 主题 在 日 淄 开 发 中 使 用 频率 略 低 ， 但 是 对 它们 有 一 害 
的 了 解 仍 然 是 很 有 必要 的 ， 下 面 分 别 介绍 它们 的 使 用 场景 。 


我 们 知道 ， 不 管 程序 怎么 写 都 很 难 避 免 不 crash， 当 程序 crash 后 虽 
然 无 法 让 其 再 继续 运行 ， 但 是 如 果 能 够 知道 程序 crash 的 原因 ， 那 么 就 
可 以 修复 错误 。 但 是 很 多 时 候 产 品 发 布 后 ， 如 采用 户 在 使 用 时 发 生 了 
crash， 这 个 crash 信 息 是 很 难 获 取 到 的 ， 这 非常 不 利于 一 个 产品 的 持续 
发 展 。 其 实 可 以 通过 CrashHandler 来 监视 应 用 的 crash 信 息 ， 给 程序 设 
置 一 个 CrashHandler， 这 样 当 程序 crash 时 束 会 调用 CrashHandler 的 
uncaughtException 方 法 。 在 这 个 方法 中 我 们 可 以 获取 crash 信 息 并 上 传 
到 服务 器 ， 通 过 这 种 方式 服务 端 就 能 监控 程序 的 运行 状况 了 ， 在 后 续 
的 版 本 开发 中 ， 开 发 人 员 就 可 以 对 一 些 错误 进行 修复 了 。 


在 Android 中 ， 有 一 个 限制 ， 那 束 古 整个 应 用 的 方法 数 不 能 超过 
65536， 否 则 整 会 出 现 编译 错误 ， 并 且 程 序 也 无 法 成 功 地 安 狠 到 手机 
FEF。 当 项 目 日 益 庞 大 后 这 个 问题 环比 较 容易 过 到 ，Google 提 供 了 
multidex 方 案 专 门 用 于 解决 这 个 问题 ， 通 过 将 一 个 dex 文 件 拆 分 为 多 个 
dex 文 件 来 避免 单个 dex 文 件 方法 数 越界 的 问题 。 


方法 数 越界 的 另 一 种 解决 方案 是 动态 加 载 。 动 态 加 载 可 以 直接 加 
载 一 个 dex 形 式 的 文件 ， 将 部 分 代码 打包 到 一 个 单独 的 dex 文 件 中 (也 
可 以 是 dex 格 式 的 jar 或 者 apk) ， 并 在 程序 运行 时 根据 需要 去 动态 加 载 


dex 中 的 类 ， 这 种 方式 既 可 以 解决 缓解 方 法 数 越界 的 问题 ， 也 可 以 为 程 
序 提 供 按 需 加 载 的 特性 ， 同 时 这 还 为 应 用 按 模块 更 新 提供 了 可 能 性 。 


反 编 译 在 应 用 开发 中 用 得 不 是 很 多 ， 但 是 很 多 时 候 我 们 需要 人 研究 
其 他 产品 的 实现 思路 ， 这 个 时 候 就 需要 反 编译 了 。 在 Android 中 反 编译 
主要 通过 dex2jar 以 及 apktool 来 完成 。dex2jar 可 以 将 一 个 apk 转 成 一 个 jar 
包 ， 这 个 jar 包 再 通过 反 编译 工 具 jd-gui 来 打开 就 可 以 查看 到 反 编 译 后 的 
Java 代 码 了 。Apktool 主 要 用 于 应 用 的 解 包 和 二 次 打包 ， 实 际 上 通过 
Apktool 的 二 次 打包 可 以 做 很 多 事情 ， 甚 至 是 一 些 违法 的 事情 。 目 前 不 
少 公 司 都 有 专门 的 反 编 译 团 队 ， 世 称 逆 加 团队 ， 他 们 做 的 事情 会 更 加 
深入 ， 但 是 对 于 应 用 开发 者 来 说 并 不 需要 了 解 那 么 多 深入 的 逆 癌 知 
识 ， 因 此 本 章 仅 仅 介 绍 一 些 人 简单 常用 的 反 编译 方法 。 


13.1 ”使 用 CrashHandler 来 获取 应 
用 的 crash 信 息 


Android 应 用 不 可 避免 地 会 发 生 crash， 也 称 之 为 朋 和 站， 无 论 你 的 程 
序 写 得 多 么 完美 ， 总 是 无 法 完全 避免 crash 的 发 生 ， 可 能 是 由 于 Android 
系统 底层 的 bug， 也 可 能 是 由 于 不 充分 的 机 型 适 配 或 者 是 精 糕 的 网 络 状 
况 。 当 crash 发 生 时 ， 系 统 会 kill 抒 正在 执行 的 程序 ， 现 象 瓯 是 内 退 或 者 
提示 用 户 程序 已 停止 运行 ， 这 对 用 户 来 说 是 很 不 友好 的 ， 也 是 开发 者 
所 不 愿意 看 到 的 。 更 糟糕 的 是 ， 当 用 户 发 生 了 crash， 开 发 者 却 无 法 得 
知 程序 为 何 crash， 即 便 开 发 人 员 想 去 解决 这 个 crash， 但 是 由 于 无 法 知 
道 用 户 当 时 的 crash 信 息 ， 所 以 往往 也 无 能 为 力 。 和 亚运 的 是 ，Android 提 
供 了 处 理 这 类 问题 的 方法 ， 请 看 下 面 Thread 类 中 的 一 个 方法 


setDefaultUncaughtExceptionHandler: 


/** 
* Sets the default uncaught exception handler. This 
handler is invoked in 
* case any Thread dies due to an unhandled exception. 
* @param handler 
$ The handler to set or null. 
=) 
public static void 
setDefaultUncaughtExceptionHandler (UncaughtException- 
Handler handler) { 
Thread.defaultUncaughtHandler = handler; 


} 


从 方法 的 字面 意义 来 看 ， 这 个 方法 好 像 可 以 设置 系统 的 默认 异常 
处 理 器 ， 其 实 这 个 方法 就 可 以 解决 上 面 所 提 到 的 crash 问 题 。 当 crash 发 
A AY MR, AA Zt RE = 回调 UncaughtExceptionHandler 的 
uncaughtException 方 法 ， 在 uncaughtException 方 法 中 束 可 以 获取 到 异常 
言 轧 ， 可 以 选择 把 异常 信息 存储 到 SD 卡 中 ， 然 后 在 合适 的 时 机 通过 网 
络 将 crash 信 息 上 传 到 服务 器 上 ， 这 样 开 发 人 员 束 可 以 分 析 用 户 crash 的 
场景 从 而 在 后 面 的 版 本 中 修复 此 类 crash。 我 们 还 可 以 在 crash 发 生 时 ， 
弹出 一 个 对 话 框 告诉 用 户 程 序 crash 了 ， 然 后 再 退出 ， 这 样 做 比 内 退 要 
AU A, ° 


有 了 上 面 的 分 析 ， 现 在 读者 肯定 知道 获取 应 用 crash 信 息 的 方式 
了 。 首 先 需 要 实现 一 个 UncaughtExceptionHandler 对 象 ， 在 它 的 
uncaughtException 方 法 中 获取 异常 信息 并 将 其 存储 在 SD 卡 中 或 者 上 传 


到 服务 器 供 开 发 人 员 分 析 ， 然 后 调用 Thread 的 setDefaultUncaught- 
ExceptionHandler 方 法 将 它 设 置 为 线程 默认 的 异常 处 理 器 ， 由 于 默认 异 
常 处 理 器 是 Thread 类 的 静态 成 员 ， 因 此 它 的 作用 对 象 是 当前 进程 的 所 
有 线程 。 这 么 来 看 监听 应 用 的 crash 信 息 实 际 上 是 很 简单 的 一 件 事 ， 下 
面 是 一 个 典型 的 异常 处 理 吉 的 实现 : 


public class CrashHandler implements 
UncaughtExceptionHandler { 
private static final String TAG = "CrashHandler"; 
private static final boolean DEBUG = true; 
private static final String PATH = 
Environment .getExternal-StorageDirectory().getPath() 十 
"/CrashTest/log/"; 


private static final String FILE_NAME = "crash"; 


private static final String FILE_NAME_SUFFIX 
" trace"; 
private static CrashHandler sInstance = new 
CrashHandler(); 
private UncaughtExceptionHandler mDefaultCrashHandler; 
private Context mContext; 
private CrashHandler() { 
} 
public static CrashHandler getInstance() { 
return sInstance; 
} 
public void init(Context context) { 


mDefaultCrashHandler = 


pw.print(Build.VERSION.RELEASE); 
pw.print("_"); 
pw.println(Build.VERSION.SDK_INT); 
// 手 机 制造 商 


pw.print("Vendor: "); 


pw.println(Build.MANUFACTURER) ; 
//FRAS 
pw.print("Model: "); 


pw.println(Build.MODEL) ; 
/VCPU 架 构 
pw.print("CPU ABI: "); 
pw.printin(Build.CPU_ABI); 
t 
private void uploadExceptionToServer() { 


//TODO Upload Exception Message To Your Web Server 


} 


MEME ALA, SS DAA ARYA, CrashHandler= 4% = ih 
信息 以 及 设备 信息 写 入 SD 卡 ， 接 着 将 异常 区 给 系统 处 理 ， 系 统 会 帮 有 我 
们 中 止 程序 ， 如 果 系 统 没有 黑 认 的 异常 处 理 机 制 ， 那 么 就 目 行 中 止 。 
当然 也 可 以 选择 将 异常 信息 上 传 到 服务 器 ， 本 节 中 的 CrashHandler 并 
没有 实现 这 个 逻辑 ， 但 是 在 实际 开发 中 一 般 都 需要 将 异常 信息 上 传 到 
服务器 。 


如 何 使 用 上 面 的 CrashHandler 呢 ? 也 很 简单 ， 可 以 选择 在 
Application 初 始 化 的 时 候 为 线程 设置 CrashHandler， 如 下 所 示 。 


ZI EHNTEIR, E OR DE A NS 
THE F crash 了， 同时 还 可 以 很 方便 地 从 服务 器 上 查看 用 户 的 crash 信 
息 。 需 要 注意 的 是 ， 代 码 中 被 catch 的 异常 不 会 交 给 CrashHandler 人 处 
理 ，CrashHandler 只 能 收 到 那些 未 被 捕获 的 异常 。 下 面 我 们 惑 模拟 一 
下 发 生 crash 的 情形 ， 看 程序 是 如 何 处 理 的 ， 如 下 所 示 。 


super .onCreate(savedInstanceState); 
setContentView(R.layout.activity_crash); 
initView(); 

J 

private void initView() { 
mButton = (Button) findViewById(R.id.button1); 
mButton.setOnClickListener(this); 

J 

@Override 

public void onClick(View v) { 
if (v == mButton) { 

// ERERNFFENHFNM, ANNE Nat FE 


throw new RuntimeException "BEN FH: 这 是 自己 抛 


出 的 异常 ") ; 


} 


在 上 面 的 测试 代码 中 ， 给 按钮 加 一 个 单 击 事件 ， 在 onClick 中 人 为 
抛 出 一 个 运行 时 异常 ， 这 个 时 候 程 序 束 crash 了 ， 看 看 异常 处 理 器 为 我 
们 做 了 什么 。 从 图 13-1 中 可 以 看 出 ， 异 常 处 理 器 为 我 们 创建 了 一 个 日 
志文 件 ， 打 开 日 志文 件 ， 可 以 看 到 手机 的 信息 以 及 异常 发 生 时 的 调用 
栈 ， 有 了 这 些 内 容 ， 开 发 人 员 束 很 容易 定位 问题 了 。 从 图 13-1 中 的 函 
数 调 用 栈 可 以 看 出 ，CrashActivity 的 28 行 发 生 了 RuntimeException， 再 
看 一 下 CrashActivity NH, 发现 28 行 的 确 抛 出 了 一 个 
RuntimeException， 这 说 明 CrashHandler 已 经 成 功 地 获取 了 未 被 捕获 的 
异常 信息 ， 从 现在 开始 ， 为 应 用 加 上 默认 异常 事件 处 理 器 吧 。 


O ç ul @ & © = uil @ 22:59 


O MA Os crash2015-05-28 22:58:43.trace 
2015-05-28 22:58:43 

App Version: 1.0_1 

OS Version: 4.1.1_16 
Vendor: Xiaomi 

pa 5-05-28 22:58:49.trace Model: MI 2S 


CPU ABI: armeabi-v7a 


CrashTest log 


crash2015-05-28 22:58:43.trace 
; 


java.lang.RuntimeException: 自 定义 异常 : 这 
是 自己 抛 出 的 异常 

at com.ryg.crashtest.CrashActivity. 
onClick(CrashActivity.java:29) 

at android.view. View.performClick(View. 
java:4171) 

at android.view. View$PerformClick. 
run(View.java:17097) 

at android.os.Handler. 
handleCallback(Handler.java:6 15) 

at android.os.Handler. 
dispatchMessage(Handler.java:92) 

at android.os.Looper.loop(Looper.java: 137) 

at android.app.ActivityThread. 
main(ActivityThread.java:491 4) 

at java.lang.reflect.Method. 
invokeNative(Native Method) 

at java.lang.reflect.Method.invoke(Method. 
java:511 


图 13-1 ”CrashHandler 获 取 的 异常 信息 


13.2 ”使 用 multidex 来 解决 方法 数 
越界 


在 Android 中 单个 dex 文 件 所 能 够 包含 的 最 大 方法 数 为 65536， 这 包 
E Android FrameWork、 依 赖 的 jar 包 以 及 应 用 本 和 里 的 代码 中 的 所 有 方 
法 。65536 是 一 个 很 大 的 数 ， 一 般 来 说 一 个 简单 应 用 的 方法 数 的 确 很 难 
达到 65536， 但 是 对 于 一 些 比较 大 型 的 应 用 来 说 ，65536 束 很 容易 达到 
了 。 当 应 用 的 方法 数 达 到 65536 后 ， 编 译 絮 束 无 法 完成 编译 工作 并 抛 出 
类 似 下 面 的 异 第 : 


另外 一 种 情况 有 所 不 同 ， 有 时 候 方法 数 并 没有 达到 65536， 并 且 编 
译 器 也 正常 地 完成 了 编译 工作 ， 但 是 应 用 在 低 版 本 手机 安装 时 异常 中 
ik, RRO: 


E/dalvikvm: Optimization failed 
E/installd: dexopt failed on '/data/dalvik- 
cache/data@app@com.ryg. 


multidextest-2.apk@classes.dex' res = 65280 


为 什么 会 出 现 这 种 情况 呢 ? 其 实 是 这 样 的 ，dexopt 是 一 个 程序 ， 
应 用 在 安装 时 ， 系 统 会 通过 dexopt 来 优化 dex 文 件 ， 在 优化 过 程 中 
dexopt 玉 用 一 个 固定 大 小 的 缓冲 区 来 存储 应 用 中 所 有 方法 的 信息 ， 这 
个 缓冲 区 就 是 LinearAlloc。LinearAlloc 缓 冲 区 在 新 版 本 的 Android 系 统 
中 其 大 小 是 8MB 或 者 16MB， 但 是 在 Android 2.2 和 2.3 中 却 只 有 5MB， 
当 待 安装 的 apk 中 的 方法 数 比 较 多 时 ， 尽 管 它 还 没有 达到 65536 这 个 上 
限 ， 但 是 它 的 存储 空间 仍然 有 可 能 超出 5MB， 这 种 情况 下 dexopt 程 序 
瓯 会 报错 ， 从 而 导致 安装 失败 ， 这 种 情况 主要 在 2.x 系 列 的 手机 上 出 
现 。 


可 以 看 到 ， 不 管 是 编译 时 方法 数 越界 还 是 安装 时 的 dexopt 错 误 ， 
它们 都 给 开发 过 程 带 来 了 很 大 的 困扰 。 从 目前 的 Android 版 本 的 市 场 占 
ARRIM, Android 3.0 以 下 的 手机 仍然 占据 着 不 到 10% 的 比率 ， 目 前 
主流 的 应 用 都 不 可 能 放弃 Android 3.0 以 下 的 用 户 ， 对 于 这 些 应 用 来 
说 ， 方 法 数 越界 就 是 一 个 必须 要 解决 的 问题 了 。 


如 何 解 决 方法 数 越界 的 问题 呢 ? 我 们 首 移 想到 的 肯定 征 删 除 无 用 
的 代码 和 第 三 方 库 。 没 错 ， 这 的 确 是 必须 要 做 的 工作 ， 但 是 很 多 情 疯 
下 即使 删除 了 无 用 的 代码 ， 方 法 数 仍 然 越界 ， 这 个 时 候 该 垮 么 办 呢 ? 


针对 这 个 问题 ， 之 前 很 多 应 用 都 会 考虑 采用 插件 化 的 机 制 来 动态 加 载 
部 分 dex， 通 过 将 一 个 dex 拆 分 成 两 个 或 多 个 dex， 这 就 在 一 定 程度 上 解 
决 了 方法 数 越界 的 问题 。 但 是 插件 化 是 一 套 重 量 级 的 技术 方案 ， 并 且 
其 兼容 性 问题 往往 较 多 ， 从 单纯 解决 方法 数 越界 的 角度 来 说 ， 插 件 化 
并 不 是 一 个 非常 适合 的 方案 ， 关 于 插件 化 的 意义 将 在 第 13.3 节 中 进行 
介绍 。 为 了 解决 这 个 问题 ，Google 在 2014 年 提出 了 multidex 的 解决 方 
案 ， 通 过 multidex 可 以 很 好 地 解决 方法 数 越界 的 问题 ， 并 且 使 用 起 来 
FE Fs fal EE o 


TE Android 5.0 LA Bij (€ FA multidex # 2 5| A Google fe Pt HY) android- 
support-multidex.jar 这 个 jar 包 ， 这 个 jar 包 可 以 在 Android SDK H>k FAY 
extras/android/support/multidex/library/ libs 下 面 找到 。 从 Android 5.0 开 
始 ，Android 默 认 文 持 了 multidex， 它 可 以 从 apk 中 加 载 多 个 dex 文 件 。 
Multidex 方 案 主要 是 针对 AndroidStudio 和 Gradle 编 译 环境 的 ， 如 果 是 
Eclipse 和 ant 那 瓯 复杂 一 些 ， 而 且 由 于 AndroidStudio 作 为 官方 IDE 其 最 
终 会 完全 替代 Eclipse ADT， 因 此 本 节 中 也 不 再 介绍 Eclipse 中 配置 
multidex 的 细节 了 。 


在 AndroidStudio 和 Gradle 编 译 环境 中 ， 如 果 要 使 用 multidex， 首 先 
要 使 用 Android SDK Build Tools 21.1 及 以 上 版 本 ， 接 着 修改 工程 中 app 
目录 下 的 build.gradle 文 件 ， 在 defaultConfig 中 添加 multiDexEnabled true 
这 个 配置 项 ， 如 下 所 示 。 关 于 如 何 使 用 AndroidStudio 和 Gradle 请 读者 
目 行 查看 相关 资料 ， 这 里 不 再 介绍 。 


android { 
compileSdkVersion 22 
buildToolsVersion "22.0.1" 


defaultConfig { 


接着 还 需要 在 dependencies 中 添加 multidex 的 依赖 : compile 
'com.android.support: multidex:1.0.0', XI FPS ° 


最 终 配 置 完 成 的 build.gradle 文 件 如 下 所 示 ， 其 中 加 粗 的 部 分 是 专 
门 为 multidex 所 添加 的 配置 项 : 


经 过 了 上 面 的 过 程 ， 还 需要 做 另 一 项 工作 ， 那 就 是 在 代码 中 加 入 
文 持 multidex 的 功能 ， 这 个 过 程 是 比较 简单 的 ， 有 三 种 方案 可 以 选 。 


第 一 种 方案 ， 在 manifest 文件 中 指定 Application 为 
MultiDexApplication， 如 下 所 示 。 


第 二 种 方案 ， 让 应 用 的 Application 继 承 MultiDexApplication ， 比 
如 : 


第 三 种 方案 ， 如 果 不 想 让 应 用 的 Application 继承 
MultiDexApplication, SH] L 144% E 5 Application’) attachBaseContext 
方法 ， 这 个 方法 比 Application 的 onCreate 要 先 执行 ， 如 下 所 示 。 


MultiDex.install(this); 


} 


现在 所 有 的 工作 都 已 经 完成 了 ， 可 以 发 现 应 用 不 但 可 以 编译 通过 
了 并 且 还 可 以 在 Android 2.x 手 机 上 面 正 常安 装 了 。 可 以 发 现 ，multidex 
使 用 起 来 还 是 很 简单 的 ， 对 于 一 个 使 用 multidex 方 案 的 应 用 ， 采 用 了 
上 面 的 配置 项 ， 如 果 这 个 应 用 的 方法 数 没 有 越界 ， 那 么 Gradle 并 不 会 
生成 多 个 dex 文 件 ， 如 宁 方 法 数 越 界 后 ，Gradle 束 会 在 apk 中 打包 2 个 或 
多 个 dex 文 件 ， 具 体会 打包 多 少 个 dex 文 件 要 看 当前 项 目的 代码 规模 。 
图 13-2 展 示 了 采用 mnultidex 方 案 的 apk 中 多 个 dex 的 分 布 情形 。 


图 13-2 ”普通 apk 和 采用 multidex 方 案 的 apk 


上 面 介 绍 的 是 multidex 默 认 的 配置 ， 还 可 以 通过 build.gradle 文 件 中 
一 些 其 他 配置 项 来 定制 dex 文 件 的 生成 过 程 。 在 有 些 情况 下 ， 可 能 需要 
指定 主 dex 文 件 中 所 要 包含 的 类 ， 这 个 时 候 就 可 以 通过 --main-dex-list 选 
项 来 实现 这 个 功能 。 下 面 是 修改 后 的 build.gradle 文 件 ， 在 里 面 添加 了 
afterEvaluate 区 域 ， 在 afterEvaluate 区 域内 部 采用 了 --main-dex-list 选 项 
来 指定 主 dex 中 要 包含 的 类 ， 如 下 所 示 。 


def listFile = project.rootDir.absolutePath + 
'/app/maindexlist.txt' 
println "root dir:" + project.rootDir.absolutePath 
printin "dex task found: " + dx.name 
if (dx.additionalParameters == null) { 


dx.additionalParameters = [] 


} 
dx.additionalParameters += '--multi-dex' 
dx.additionalParameters += '--main-dex-list=' + 
listFile 
dx.additionalParameters += '--minimal-main-dex' 
} 
} 


dependencies { 
compile fileTree(dir: 'libs',include: ['*.jar']) 
compile 'com.android.support:appcompat-v7:22.1.1' 


compile 'com.android.support:multidex:1.0.0' 


在 上 面 的 配置 文件 中 ，--multi-dex 表 示 当 方法 数 越界 时 则 生成 多 
个 dex 文 件 ，--main-dex-list 指 定 了 要 在 主 dex 中 打包 的 类 的 列表 ，-- 
minimal-main-dex 表 明 只 有 --main-dex-list 所 指定 的 类 才能 打包 到 主 dex 
中 。 它 的 输入 是 一 个 文件 ， 在 上 面 的 配置 中 ， 它 的 输入 是 工程 中 app 目 
录 下 的 maindexlist.txt 这 个 文件 ， 在 maindexlist.txt 中 则 指定 了 一 系列 的 
类 ， 所 有 在 maindexlisttxt 中 的 类 都 会 被 打包 到 主 dex 中 。 注 意 
maindexlist.txt 这 个 文件 名 是 可 以 修改 的 ， 但 是 它 的 内 容 必 须要 遵守 一 
定 的 格式 ， 下 面 是 一 个 示例 ， 这 种 格式 是 固定 的 。 


com/ryg/multidextest/TestApplication.class 
com/ryg/multidextest/MainActivity.class 

// multidex 
android/support/multidex/MultiDex.class 
android/support/multidex/MultiDexApplication.class 
android/support/multidex/MultiDexExtractor.class 
android/support/multidex/MultiDexExtractor$1.class 
android/support/multidex/MultiDex$V4.class 
android/support/multidex/MultiDex$V14.class 
android/support/multidex/MultiDex$V19.class 
android/support/multidex/ZipUtil.class 


android/support/multidex/ZipUtil$CentralDirectory.class 


程序 编译 后 可 以 反 编 译 apk 中 生成 的 主 dex 文 件 ， 可 以 发 现 主 dex 文 
件 的 确 只 有 maindexlisttxt 文 件 中 所 声明 的 类 ， 读 者 可 以 目 行 演 试 。 
maindexlist.txt 这 个 文件 很 多 时 候 都 是 可 以 通过 脚本 来 自动 生成 内 容 
的 ， 这 个 脚本 需要 根据 当前 的 项 目 自行 实现 ， 如 果 不 采 用 脚本 ， 人 工 
编辑 maindexlist.txt 也 是 可 以 的 。 


需要 注意 的 是 ，mnultidex 的 jar 包 中 的 9 个 类 必须 也 要 打包 到 主 dex 
中 ， 人 否则 程序 运行 时 会 扫 出 异常 ， 告 知 无 法 找到 multidex 相 关 的 类 。 
这 是 因为 Application 对 象 被 创建 以 后 会 在 attachBaseContext 方 法 中 通过 
MultiDex.install(this) 来 加 载 其 他 dex 文 件 ， 这 个 时 候 如 果 MultiDex 相 关 
的 类 不 在 主 dex 中 ， 很 显然 这 些 类 是 无 法 被 加 载 的 ， 那 么 程序 执行 就 会 
出 错 。 同 时 由 于 Application 的 成 员 和 代码 块 会 先 于 attachBaseContext 方 
法 而 初始 化 ， 而 这 个 时 候 其 他 dex 文 件 还 没有 被 加 载 ， 因 此 不 能 在 
Application 的 成 员 以 及 代码 块 中 访问 其 他 dex 中 的 类 ， 否 则 程序 也 会 


为 无 法 加 载 对 应 的 类 而 中 止 执行 。 在 下 面 的 代码 中 ， 模 拟 了 这 种 场 
景 ， 在 Application 的 成 员 中 使 用 了 其 他 dex 文 件 中 的 类 View1 。 


上 面 的 代码 会 导致 如 下 运行 错误 ， 因 此 在 实际 开发 中 要 避免 这 个 
PR 


android.app.Instrumentation.newApplication(Instrumentation.java 


:975) 


android.app.LoadedApk.makeApplication(LoadedApk.java:504) 


Mnultidex 方 法 虽然 很 好 地 解决 了 方法 数 越界 这 个 问题 ， 但 它 也 是 
有 一 些 局 限 性 的 ， 下 面 是 采用 multidex 可 能 市 来 的 问题 ; 


(1) 应 用 局 动 速度 会 降低 。 由 于 应 用 局 动 时 会 加 载 额外 的 dex 文 
件 ， 这 将 导致 应 用 的 局 动 速度 降低 ， 甚 至 可 能 出 现 ANR 现 象 ， 尤 其 是 
其 他 dex 文 件 较 大 的 时 候 ， 因 此 要 避免 生成 较 大 的 dex 文 件 。 


(2) 由 于 Dalvik linearAlloc 的 bug， 这 可 能 导致 使 用 multidex 的 应 
用 无 法 在 Android 4.0 以 前 的 手机 上 运行 ， 因 此 需要 做 大 量 的 兼容 性 测 
试 。 同 时 由 于 Dalvik linearAlloc 的 bug， 有 可 能 出 现 应 用 在 运行 中 由 于 
采用 了 multidex 方 案 从 而 产生 大 量 的 内 存 消 耗 的 情况 ， 这 会 导致 应 用 
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在 实际 的 项 目 中 ， (1) 中 的 现象 是 客观 存在 的 ， 但 是 (2) 中 的 
现象 目前 极 少 遇 到 ， 综 合 来 说 ，multidex 还 是 一 个 解决 方法 数 越界 非 
常 好 的 方案 ， 可 以 在 实际 项 目 中 使 用 。 


13.3 ”Android 的 动态 加 载 技 术 


动态 加 载 报 术 (也 叫 插 件 化 技术 ) 在 技术 驱动 型 的 公司 中 扮演 着 
相当 重要 的 角色 ， 当 项 目 越 来 越 庞大 的 时 候 ， 需 要 通过 插件 化 来 减轻 


应 用 的 内 存 和 CPU 占用 ， 还 可 以 实现 热 播 拔 ， 即 在 不 发 布 新 版 本 的 情 
况 下 更 新 某 些 模块 。 动 态 加 载 是 一 项 很 复杂 的 技术 ， 这 里 主要 介绍 动 
态 加 载 技 术 中 的 三 个 基础 性 问题 ， 至 于 完整 的 动态 加 载 技术 的 实现 请 
参考 笔者 发 起 的 开源 插件 化 框架 DL 
https://github.com/singwhatiwanna/dynamic-load-apk ° 项 日 期 间 有 多 位 
开发 人 员 一 起 贡献 代码 。 


不 同 的 插件 化 方案 各 有 各 的 特色 ， 但 是 它们 都 必须 要 解决 三 个 基 
础 性 问题 : 资源 访问 、Activity 生 命 周 期 的 管理 和 ClassLoader 的 管理 。 
在 介绍 它们 之 前 ， 首 先 要 明日 答 主 和 插件 的 概念 ， 和 宿主 是 指 普 通 的 
apk， 而 插件 一 般 是 指 经 过 处 理 的 dex 或 者 apk， 在 主流 的 插件 化 框架 中 
多 采用 经 过 特殊 处 理 的 apk 来 作为 插件 ， 处 理 方式 往往 和 编译 以 及 打包 
环节 有 关 ， 另 外 很 多 插件 化 框架 都 需要 用 到 代理 Activity 的 概念 ， 插 件 
Activity 的 启动 大 多 数 是 借助 一 个 代理 Activity 来 实现 的 。 


1. 资源 访问 


我 们 知道 ， 宿 主 程序 调 起 未 安装 的 插件 apk， 一 个 很 大 的 问题 惑 是 
资源 如 何 访问 ， 具 体 来 说 就 是 插件 中 几 古 以 R 开 头 的 资源 都 不 能 访问 
了 。 这 古 因为 答 主 程序 中 并 没有 搬 件 的 资源 ， 所 以 通过 R 来 加 载 插 件 
的 资源 是 行 不 通 的 ， 程 序 会 抛 出 异常 : 无 法 找到 某 某 id 所 对 应 的 资 
源 。 针 对 这 个 问题 ， 有 人 提出 了 将 插件 中 的 资源 在 宿主 程序 中 也 预 置 
一 份 ， 这 虽然 能 解决 问题 ， 但 是 这 样 束 会 产生 一 些 束 端 。 首 先 ， 这 样 
下 需要 答 主 和 插件 同时 持 有 一 份 相同 的 资源 ， 增 加 了 窒 主 apk 的 大 小 ; 
其 次 ， 在 这 种 模式 下 ， 每 次 发 布 一 个 插件 都 需要 将 资源 复制 到 宿主 程 
序 中 ， 这 意味 着 每 发 布 一 个 插件 都 要 更 新 一 下 御 主 程序 ， 这 了 就 和 插件 
化 的 思想 相 违 痛 了 。 因 为 插件 化 的 目的 束 是 要 减 小 答 主 程序 apk 包 的 大 
小 ， 同 时 降低 答 主 程序 的 更 新 频率 并 做 到 目 由 疡 载 模 块 ， 所 以 这 种 方 
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一 种 方式 ， 首 先 将 搬 件 中 的 资源 解压 出 来 ， 然 后 通过 文件 流 去 读 取 次 
源 ， 这 样 做 理论 上 是 可 行 的 ， 但 是 实际 操作 起 来 还 是 有 很 大 难度 的 。 
目 先 不 同 资源 有 不 同 的 文件 流 格 式 ， 比 如 图 片 、XML 等 ， 其 次 针对 不 
同 设备 加 载 的 资源 可 能 是 不 一 样 的 ， 如 何 选择 合适 的 资源 也 古 一 个 需 
要 解决 的 问题 ， 基 于 这 两 点 ， 这 种 方法 也 不 建议 使 用 ， 因 为 它 实现 起 
来 有 较 大 难度 。 为 了 方便 地 对 插件 进行 资源 管理 ， 下 面 给 出 一 种 合理 
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我 们 知道 ，Activity 的 工作 主要 是 通过 ContextImpl 来 完成 的 ， 
Activity 中 有 一 个 叫 mBase 的 成 员 变 量 ， 它 的 类 型 天 是 ContextImp1l。 注 
意 到 Context 中 有 如 下 两 个 抽象 方法 ， 看 起 来 是 和 资源 有 关 的 ， 实 际 上 
Context 束 是 通过 它们 来 获取 资源 的 。 这 两 个 抽象 方法 的 真正 实现 在 
ContextImpl 中 ， 也 就 是 说 ， 只 要 实现 这 两 个 方法 ， 就 可 以 解决 资源 问 
题 了 。 


/** Return an AssetManager instance for your application's 
package. */ 
public abstract AssetManager getAssets(); 
/** Return a Resources instance for your application's 
package. */ 


public abstract Resources getResources(); 


下 面 给 出 具体 的 实现 方式 ， 首 先 要 加 载 apk 中 的 资源， 如 下 所 示 。 


protected void loadResources() { 


try { 


AssetManager assetManager = 


AssetManager.class.newInstance(); 
Method addAssetPath = 
assetManager .getClass().getMethod 
("addAssetPath",String.class); 
addAssetPath.invoke(assetManager,mDexPath) ; 
mAssetManager = assetManager; 
} catch (Exception e) { 
e.printStackTrace(); 
} 
Resources superRes = super.getResources(); 
mResources = new 
Resources(mAssetManager, superRes.getDisplay-Metrics(), 
superRes.getConfiguration()); 
mTheme = mResources.newTheme(); 


mTheme.setTo(super.getTheme()); 
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通过 调用 AssetManager 中 的 addAssetPath 方 法 ， 我 们 可 以 将 一 个 apk 中 
的 资源 加 载 到 Resources 对 象 中 ， 由 于 addAssetPath 是 隐藏 API 我 们 无 法 
直接 调用 ， 所 以 只 能 通过 反射 。 下 面 是 它 的 声明 ， 通 过 注释 我 们 可 以 
看 出 ， 传 递 的 路 径 可 以 是 zip 文 件 也 可 以 是 一 个 资源 日 录 ， 而 apk 束 是 
一 个 zip， 所 以 直接 将 apk 的 路 径 传 给 它 ， 资 源 束 加 载 到 AssetManager 中 

了 。 然 后 再 通过 AssetManager 来 创建 一 个 新 oo 通过 这 
个 对 象 我 们 就 可 以 访问 插件 apk 中 的 资源 了 ， 这 样 一 来 问题 束 解 决 了 了。 


接着 在 代理 Activity 中 实现 getAssets() 和 getResources()， 如 下 所 
示 。 天 于 代理 Activity 的 含义 请 参看 DL 开源 插件 化 框架 的 实现 细节 ， 
这 里 不 再 详细 描述 了 。 
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2. Activity 生 命 周 期 的 管理 


管理 Activity 生 命 周 期 的 方式 各 种 各 样 ， 这 里 只 介绍 两 种 : 反射 方 
式 和 接口 方式 。 反 射 的 方式 很 好 理解 ， 首 先 通过 Java 的 反射 去 获取 
Activity 的 各 种 生命 周期 方法 ， 比 如 onCreate、onStart、onResume 等 ， 
然后 在 代理 Activity 中 去 调用 插件 Activity 对 应 的 生命 周期 方法 即 可 ， 
如 下 所 示 。 


使 用 反射 来 管理 插件 Activity 的 生命 周期 是 有 缺点 的 ， 一 方面 是 反 
射 代码 写 起 来 比较 复杂 ， 另 一 方面 是 过 多 使 用 反射 会 有 一 定 的 性 能 
销 。 下 面 介 绍 接口 方式 ， 接 口 方式 很 好 地 解决 了 反射 方式 的 不 足 之 
处 ， 这 种 方式 将 Activity 的 生命 周期 方法 提取 出 来 作为 一 个 接口 (比如 
叫 DLPlugin) ， 然 后 通过 代理 Activity 去 调用 插件 Activity 的 生命 周期 方 
法 ， 这 样 就 完成 了 插件 Activity 的 生命 周期 管理 ， 并 且 没 有 采用 反射 ， 
这 就 解决 了 性 能 问题 。 同 时 接口 的 声明 也 比较 简单 ， 下 面 是 DLPlugin 
的 声明 : 


public void onActivityResult(int requestCode, int 
resultCode, Intent data); 
public void onResume(); 
public void onPause(); 
public void onStop(); 
public void onDestroy(); 
public void onCreate(Bundle savedInstanceState); 
public void setProxy(Activity proxyActivity,String 
dexPath); 
public void onSavelnstanceState(Bundle outState); 
public void onNewIntent(Intent intent); 
public void onRestoreInstanceState(Bundle 
savedInstanceState); 
public boolean onTouchEvent (MotionEvent event); 
public boolean onKeyUp(int keyCode, KeyEvent event); 
public void onWindowAttributesChanged(LayoutParams 
params); 
public void onWindowFocusChanged(boolean hasFocus); 


public void onBackPressed(); 


在 代理 Activity 中 只 需要 按 如 下 方式 即 可 调用 插件 Activity 的 生命 
周期 方法 ， 这 就 完成 了 插件 Activity 的 生命 周期 的 管理 。 


@Override 


通过 上 述 代 码 应 该 不 难 理解 接口 方式 对 插件 Activity 生 命 周 期 的 管 
理 思想 ， 其 中 mRemoteActivity 就 是 DLPlugin 的 实现 。 


3. 插件 ClassLoader 的 管理 


为 了 更 好 地 对 多 插件 进行 支持 ， 需 要 合理 地 去 管理 各 个 搬 件 的 
DexClassoader， 这 样 同一 个 揪 件 就 可 以 采用 同一 个 ClassLoader 去 加 载 
类 ， 从 而 避免 了 多 个 ClassLoader 加 载 同 一 个 类 时 所 引发 的 类 型 转换 错 
误 。 在 下 面 的 代码 中 ， 通 过 将 不 同 插件 的 ClassLoader 存 储 在 一 个 
HashMap 中 ， 这 样 瓯 可 以 保证 不 同 插件 中 的 类 彼此 互 不 干扰 。 


public class DLClassLoader extends DexClassLoader { 
private static final String TAG = "DLClassLoader"; 
private static final HashMap<String,DLClassLoader> 
mPluginClassLoaders 
= new HashMap<String,DLClassLoader>(); 
protected DLClassLoader(String dexPath,String 


optimizedDirectory,String libraryPath,ClassLoader parent) { 


super (dexPath, optimizedDirectory, libraryPath, parent); 
} 
/** 
* return a available classloader which belongs to 
different apk 
E 
public static DLClassLoader getClassLoader (String 
dexPath, Context 
context,ClassLoader parentLoader) { 


DLClassLoader dLClassLoader 


mPluginClassLoaders.get(dexPath); 
if (dLClassLoader != null) 


return dLClassLoader; 


File dexOutputDir 
context.getDir("dex", Context .MODE_PRIVATE) ; 


final String dexOutputPath 
dex0utputDir.getAbsolutePath(); 
dLClassLoader = new 


DLClassLoader (dexPath, dexOutputPath, null, 


parentLoader); 
mPluginClassLoaders.put(dexPath, dLClassLoader ); 


return dLClassLoader; 


} 
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述 清楚 的 ， 男 外 插件 化 作为 一 种 核心 技术 ， 需 要 开发 者 有 较 深 的 开发 
功底 才能 够 很 好 地 理解 ， 因 此 本 市 的 内 容 更 多 是 让 读者 对 插件 化 开发 
有 一 个 感性 的 了 解 ， 细 节 上 还 需要 读者 目 己 去 外 研 ， 也 可 以 通过 DL 揪 
件 化 框架 去 深入 地 学 习 。 


13.4 反 编 译 初 步 


反 编 译 属于 逆向 工程 中 的 一 种 ， 反 编译 有 很 多 高 级 的 手段 和 工 
具 ， 本 市 只 是 为 了 让 读者 掌握 初级 的 反 编译 手段 ， 毕 葛 对 于 一 个 不 是 
专业 做 逆 癌 的 开发 人 员 来 说 ， 的 确 没 有 必要 花 大 量 时 间 去 研究 反 编 译 
的 一 些 高 级 技巧 。 本 主要 介绍 两 方面 的 内 容 ， 一 方面 是 介绍 使 用 
dex2jar 和 jd-gui 来 反 编 译 apk 的 方式 ， 另 一 方面 是 介绍 使 用 apktool 来 对 
apk 进 行 二 次 打包 的 方式 。 下 面 是 这 三 个 反 编 译 工具 的 下 载 地 址 。 


apktool: http://ibotpeaches.github.io/Apktool/ 
dex2jar: https://github.com/pxb1988/dex2jar 


jd-gui: http://jd.benow.ca/ 


13.4.1 ”使 用 dex2jar 和 jd-gui 反 编译 
apk 


Dex2jar 和 jd-gui 在 很 多 操作 系统 上 都 可 以 使 用 ， 本 节 只 介绍 它们 
在 Windows 和 Linux 上 的 使 用 方式 。Dex2jar 是 一 个 将 dex 文 件 转 换 为 jar 
包 的 工具 ， 它 在 Windows 和 Linux 上 都 有 对 应 的 版 本 ，dex 文 件 来 源 于 
apk， 将 apk 通 过 zip 包 的 方式 解压 缩 即 可 提取 出 里 面 的 dex 文 件 。 有 了 
jar 包 还 不 行 ， 因 为 jar 包 中 都 是 class 文 件 ， 这 个 时 候 还 需要 jd-gui 将 jar 包 
进一步 转换 为 Java 代 人 码 ，jd-gui 仍 然 文 持 Windows 和 Linux ， 不 管 是 
dex2jar 还 是 jd-gui， 它 们 在 不 同 的 操作 系统 中 的 使 用 方式 都 是 一 致 的 。 


Dex2jar 是 命令 行 工具 ， 它 的 使 用 方式 如 下 : 


Linux (Ubuntu): ./dex2jar.sh classes.dex 


Windows: dex2jar.bat classes.dex 


Jd-gui 和 是 图 形 化 工具 ， 直 搂 双 击 打 开 后 通过 沫 单打 开 jar 包 即 可 碍 
看 jar 包 的 源码 。 下 面 做 一 个 示例 ， 通 过 dex2jar 和 jd-gui 来 反 编 译 13.1 贡 
中 的 示例 程序 的 apk。 首 先 将 apk 解 压 后 提取 出 classes.dex 文 件 ， 接 着 通 
过 dex2jar 反 编译 classes.dex， 然 后 通过 jd-gui 来 打开 反 编 译 后 的 jar 包 ， 
如 图 13-3 所 示 。 可 以 发 现 反 编译 后 的 结果 和 第 13.1 广 中 CrashActivity 的 
产 代码 已 经 比较 接近 了 ， 通 过 左边 的 表单 可 以 查看 其 他 类 的 反 编 译 结 
果 o 


in is A ES 


Edit Navigate Search Help 


5-H android.support.v4 
a 出 com.ryg.crashtest 
由 -四 BuildConfig 
-p D CrashActivity import android.app.Activity; 
+ »{J) CrashHandler 
H-D) TestApp 


pro com.ryg.crashtest; 


public class CrashActivity extends Activity 
implements View. OnClickListener 


private Button mButton; 


private void initView() 

{ 
Button localButton = (Button) findViewById (2131296256) ; 
this.rButton = localButton; 
this.mButton.setOnClickListener (this); 

} 


public void onClick(View paramView) 


Button localButton = this.mButton; 
if (paramView != localButton) 
return; 
throw new RuntimeExceptin ("BEXF#: Aaanu"); 
} 


protected void onCreate (Bundle paramBundle) 


super.onCreate (paramBundle) ; 
setContentView (2130903040); 
initView(); 


} 


} 


图 13-3 ”使 用 jd-gui 反 编译 jar 包 


13.4.2 ”使 用 apktool 对 apk 进 行 二 次 打 
包 


在 13.4.1 廊 中 介绍 了 dex2jar 和 jd-gui 的 使 用 方式 ， 通 过 它们 可 以 将 
一 个 dex 文 件 反 编译 为 Java 代 码 ， 但 是 u. 20. 进 
制 数 据 资源 ， 但 是 采用 apktool 豆 可 以 做 到 这 一 点 。apktool 另 外 一 个 
ee Me re o em 
包 为 山寨 应 用 ， 这 是 一 种 不 被 提倡 的 行为 ， 甚 至 是 违法 的 ， 建 议 开 发 


者 不 要 去 这 么 做 ， 但 是 掌握 以 下 二 次 打包 的 技术 对 于 个 人 技术 的 提高 
还 是 很 有 意义 的 。apktool 同 样 有 多 个 版 本 ， 这 里 同样 只 介绍 Windows 
版 和 Linux 版 ，apktool 是 一 个 命令 行 工具 ， 它 的 使 用 方式 如 下 所 示 。 这 
里 仍然 拿 13.1 节 中 的 示例 程序 为 例 ， 假 定 apk 的 文件 名 为 
CrashTest.apk ° 


Linux (Ubuntu) 
解 包 : ./apktool d -f CrashTest.apk CrashTest ° 
二 次 打包 : ./apktool b CrashTest CrashTest-fake.apk ° 


签名 : java -jar signapk.jar testkey.x509.pem testkey.pk8 CrashTest- 
fake.apk CrashTest-fake-signed.apk ° 


Windows 
解 包 : apktool.bat d -f CrashTest.apk CrashTest ° 
二 次 打包 : apktool.bat b CrashTest CrashTest-fake.apk ° 


签名 : java -jar signapk.jar testkey.x509.pem testkey.pk8 CrashTest- 
fake.apk CrashTest-fake-signed.apk ° 


需要 注意 的 是 ， 由 于 Windows 系 统 的 兼容 性 问题 ， 有 时 候 会 导致 
apktool.bat 无 法 在 Windows 的 一 些 版 本 上 正常 工作 ， 比 如 Windows 8, 
这 个 时 候 可 以 安装 Cygwin， 然 后 采用 Linux 的 方式 米 进 行 打 包 即 可 。 
除 此 之 外 ， 部 分 apk 也 可 能 会 打包 失败 ， 以 笔者 的 个 人 经 验 来 说 ， 
apktool 在 Linux 上 的 打包 成 功率 要 比 Windows 高 。 


这 里 对 上 面 的 二 次 打包 的 命令 稍 作 解释 ， 解 包 命 令 中 ，d 表 示 解 
包 ，CrashTest.apk 表 示 待 解 包 的 apk，CrashTest 表 示 解 包 后 的 文件 的 存 
储 路 径 ，-f 表 示 如 果 CrashTest 目 杂 已 经 存在 ， 那么 直接 窗 盖 它 。 


打包 命令 中 ，b 表 示 打 包 ，CrashTest 表 示 解 包 后 的 文件 的 存储 路 
径 ，CrashTest-fake.apk 表 示 二 次 打包 后 的 文件 名 。 通 过 apktool 解 包 以 
后 ， 可 以 查看 到 apk 中 的 资源 以 及 smali 文 件 ，smali 文 件 是 dex 文 件 反 编 
译 〈 不 同 于 dex2jar 的 反 编 译 过 程 ) 的 结果 。smali 有 上 自己 的 语法 并 且 可 
以 修改 ， 修 改 后 可 以 被 二 次 打包 为 apk， 通 过 这 种 方式 束 可 以 修改 apk 
的 执行 逻辑 ， 显 然 这 让 山寨 应 用 变 得 十 分 危险 。 需 要 注意 的 是 ，apk 经 
过 二 次 打包 后 并 不 能 直接 安装 ， 必 须要 经 过 签名 后 才能 安装 。 


签名 命令 中 ， 采 用 signapk.jar 来 完成 签名 ， 签 名 后 生成 的 apk 束 是 
一 个 山寨 版 的 apk， 因 为 签名 过 程 中 所 采用 的 签名 文件 不 是 官方 的 ， 最 
终 CrashTest-fake-signed.apk 束 是 二 次 打包 形成 的 一 个 山寨 版 的 apk。 对 
于 本 文中 的 例子 来 说 ，CrashTest-fake-signed.apk 安 装 后 其 功能 和 正版 
的 CrashTest.apk 是 没有 区 别 的 。 


在 实际 开发 中 ， 很 多 产品 都 会 做 签名 校 验 ， 人 简单 的 二 次 打包 所 得 
到 的 山寨 版 apk 安 猴 后 无 法 运行 。 尽 管 如 此 ， 还 是 可 以 通过 修改 smali 
的 方式 来 绕 过 签名 校 验 ， 这 就 是 为 什么 市 面 上 仍然 有 那么 多 的 山寨 版 
应 用 的 原因 。 一 般 来 说 山寨 版 应 用 都 具有 一 定 的 危害 性 ， 我 们 要 抵制 
山寨 版 应 用 以 防止 目 己 的 财产 遭受 到 损失 。 关 于 smali 的 语法 以 及 如 何 
修改 smali， 这 束 属 于 比较 深入 的 话题 了 ， 本 贡 不 再 对 它们 进行 深入 的 
介绍 ， 感 兴趣 的 话 可 以 阅读 逆 同 方面 的 专业 书籍 ， 也 可 以 阅读 笔者 之 
前 写 的 一 篇 介绍 应 用 破解 的 文章 : http://blog.csdn.net/ 
singwhatiwanna/article/details/18797493 ° 


414% ”JNI 和 NDK 编 程 


Java JNI 的 本 意 是 Java Native Interface (Java 本 地 接口 ) ， 它 是 为 
了 方便 Java 调用 C、C++ 等 本 地 代码 所 封装 的 一 层 接口 。 我 们 都 知道 ， 
Java 的 优点 是 跨 平 台 ， 但 是 作为 优点 的 同时 ， 其 在 和 本 地 交互 的 时 候 
瓯 出 现 了 短 板 。Java 的 路 平台 特性 导致 其 本 地 交互 的 能 力 不 够 强大 ， 
一 些 和 操作 系统 相关 的 特性 Java 无 法 完成 ， 于 是 Java 提 供 了 JNI 专 门 用 
于 和 本 地 代码 交互 ， 这 样 就 增强 了 Java 语 言 的 本 地 交互 能 力 。 通 过 
Java JNI， 用 户 可 以 调用 用 C、C++ 所 编写 的 本 地 代码 。 


NDK 是 Android 所 提供 的 一 个 工具 集合 ， 通 过 NDK 可 以 在 Android 
中 更 加 方便 地 通过 JNI 来 访问 本 地 代码 ， 比 如 C 或 者 C++。NDK 还 提供 
了 交叉 编译 器 ， 开 发 人 员 只 需要 简单 地 修改 mk 文件 就 可 以 生成 特定 
CPU 平台 的 动态 库 。 使 用 NDK 有 如 下 好 处 : 


(1) 提高 代码 的 安全 性 。 由 于 so 库 反 编译 比较 困难 ， 因 此 NDK 
提高 了 Android 程 序 的 安全 性 。 


(2) 可 以 很 方便 地 使 用 目前 已 有 的 C/C++ 开源 库 。 


(3) 便于 平台 间 的 移植 。 通 过 C/C++ 实现 的 动态 库 可 以 很 方便 地 
在 其 他 平台 上 使 用 。 


(4) 提高 程序 在 某 些 特定 情形 下 的 执行 效率 ， 但 是 并 不 能 明显 提 
升 Android 程 序 的 性 能 。 


由 于 JNI 和 NDK 比较 适合 在 Linux 环 境 下 开发 ， 因 此 本 文选 择 
Ubuntu 14.10 (64 位 操作 系统 ) 作为 开发 环境 ， 同 时 选择 AndroidStuio 
作为 IDE。 至 于 Windows 环 境 下 的 NDK 开 发 ， 整 体 流程 是 类 似 的 ， 有 
差别 的 只 是 和 操作 系统 相关 的 特性 ， 这 里 就 不 再 单独 介绍 了 。 在 Linux 
环境 中 ，JNI 和 NDK 开 发 所 用 到 的 动态 库 的 格式 是 以 .so 为 后 级 的 文 
件 ， 下 面 统一 简称 为 so 库 。 另 外 ， 由 于 JNI 和 NDK 主 要 用 于 底层 和 舱 入 
式 开 发 ， 在 Android 的 应 用 层 开 发 中 使 用 较 少 ， 加 上 它们 本 吴 更 加 侧重 
于 C 和 C++ 方面 的 编程 ， 因 此 本 章 只 介绍 JNI 和 NDK 的 基础 知识 ， 其 他 
更 加 深入 的 知识 点 如 果 读 者 感 兴趣 的 话 可 以 查看 专门 介绍 JNI 和 NDK 
的 书籍 。 


14.1 JNI 的 开发 流程 


JNI 的 开发 流程 有 如 下 几 步 ， 首 先 需 要 在 Java 中 声明 native 方 法 ， 
接着 用 C 或 者 C++ 实 现 native 方 法 ， 然 后 就 可 以 编译 运行 了。 


1. 在 Java 中 声明 native 方 法 
创建 一 个 类 ， 这 里 叫做 JniTest.java， 代 码 如 下 所 示 。 


package com.ryg; 
import java.lang.System; 
public class JniTest { 
static { 
System.loadLibrary("jni-test"); 
J 


public static void main(String args[]) { 


JniTest jniTest = new JniTest(); 
System.out.println(jniTest.get()); 
jniTest.set("hello world"); 

$ 

public native String get(); 


public native void set(String str); 


可 以 看 到 上 面 的 代码 中 ， 声 明了 两 个 native 方 法 : get A 
set(String)， 这 两 个 就 是 需要 在 JNI 中 实现 的 方法 。 在 JniTest 的 尖 部 有 一 
个 加 载 动态 库 的 过 程 ， 其 中 jni-test 是 so 库 的 标识 ，so 库 完整 的 名 称 为 
libjni-test.so, 这 是 加 载 so 库 的 规范 。 


2. 编译 Java 源 文件 得 到 class 文 件 ， 然 后 通过 javah 命 令 导 出 JNI 的 
头 文件 


具体 的 命令 如 下 : 


javac com/ryg/JniTest.java 


javah com.ryg.JniTest 


ral 


在 当前 目录 下 ， 会 产生 一 个 com_ryg_JniTesth 的 头 文 件 ， 它 
javah 命 令 自 动 生成 的 ， 内 容 如 下 所 示 。 


/* DO NOT EDIT THIS FILE -it is machine generated */ 
#include <jni.h> 

/* Header for class com_ryg_JniTest */ 

Hifndef _Included_com_ryg_JniTest 


#define _Included_com_ryg_JniTest 


上 面 的 代码 需要 做 一 下 说 明 ， 首 先 函 数 名 的 格式 遵循 如 下 规则 : 
Java_ 包 名 _ 类 名 方法 名 。 比 如 JniTest 中 的 set 方 法 ， 到 这 里 就 变 成 了 
JNIEXPORT void JNICALL Java_com_ryg_JniTest_set(JNIEnv 
*,jobjecbjstring)， 其 中 com_ryg 是 包 名 ，JniTest 是 类 名 ，jstring 是 代表 
的 是 set 方 法 的 String 类 型 的 参数 。 关 于 Java 和 JNI 的 数据 类 型 之 间 的 对 


应 天 系 会 在 14.3 节 中 进行 介绍 ， 这 里 只 需要 知道 Java 的 String 对 应 于 JNI 
的 jstring 即 可 。JNIEXPORT、JNICALL、JNIEnv 和 jobject 都 是 JNI 标 准 
中 所 定义 的 类 型 或 者 宏 ， 它 们 的 含义 如 下 : 


。JNIEnv*: 表示 一 个 指向 JNI 环 境 的 指针 ， 可 以 通过 它 来 访问 JNI 提 
供 的 接口 方法 ; 

。 jobject: 表示 Java 对 象 中 的 this; 

。JNIEXPORT 和 JNICALL: 它们 是 JNI 中 所 定义 的 安 ， 可 以 在 jnih 
这 个 头 文件 中 查找 到 o 


下 面 的 宏 定 义 是 必需 的 ， 它 指定 extern "C" 内 部 的 函数 采用 C 语 言 
的 命名 风格 来 编译 。 否 则 当 JNI 采 用 C++ 来 实现 时 ， 由 于 C 和 C++ 编译 
过 程 中 对 函数 的 命名 风格 不 同 ， 这 将 导致 JNI 在 链接 时 无 法 根据 范 数 名 
查找 到 具体 的 函数 ， 那 么 JNI 调 用 就 无 法 完成 。 更 多 的 细 广 实际 上 是 有 
关 C 和 C++ 编译 时 的 一 些 问题 ， 这 里 就 不 再 展开 了 。 


Hifdef _ cplusplus 
extern "C" { 


#endif 


3. 实现 JNT 方 法 


JNI 方 法 是 指 Java 中 声明 的 native 方 法 ， 这 里 可 以 选择 用 C++ 或 者 C 
来 实现 ， 它 们 的 实现 过 程 是 类 似 的 ， 只 有 少量 的 区 别 ， 下 面 分 别 用 
C++ 和 C 来 实现 JNI 方 法 。 首 先 ， 在 工程 的 主 目录 下 创建 一 个 子 目 录 ， 
名 称 随 意 ， 这 里 选择 jni 作 为 子 目 录 的 名 称 ， 然 后 将 之 前 通过 javah 生 成 
的 头 文件 com_ryg_JniTesth 复 制 到 jni 目 了 永 下 ， 接 着 创建 testcpp 和 test.c 
两 个 文件 ， 它 们 的 实现 如 下 所 示 。 


JNIEXPORT void JNICALL Java_com_ryg_JniTest_set(JNIEnv 
*env, jobject thiz, 
jstring string) { 
printf("invoke set from C\n"); 
char* Str = (char*)(*env)- 
>GetStringUTFChars(env, string, NULL); 
printf("%s\n",str); 


(*env) ->ReleaseStringUTFChars(env, string, str); 


可 以 发 现 ，test.cpp 和 testc 的 实现 很 类 似 ， 但 是 它们 对 env 的 操作 
方式 有 所 不 同 ， 因 此 用 C++ 和 C 来 实现 同一 个 JNI 方 法 ， 它 们 的 区 别 主 
要 集中 在 对 env 的 操作 上 ， 其 他 都 是 类 似 的 ， 如 下 所 示 。 


C++: env->NewStringUTF("Hello from JNI !"); 


Es (*env)->NewStringUTF(env, "Hello from JNI !") 


4. 编译 so 库 并 在 Java 中 调用 


so 库 的 编译 这 里 采用 gcc， 切 换 到 jni 目 隶 中 ， 对 于 test.cpp 和 test.c 来 
说 ， 它 们 的 编译 指令 如 下 所 示 。 


C++ : gcc -shared -I /usr/lib/jvm/java-7-openjdk- 
amd64/include -fPIC test.cpp -o libjni-test.so 
© i gcc -shared -I /usr/lib/jvm/java-7-openjdk- 


amd64/include -fPIC test.c -o libjni-test.so 


上 面 的 编译 命令 中 ，/usr/lib/jvm/java-7-openjdk-amd64 是 本 地 的 jdk 
的 安装 路 径 ， 在 其 他 环境 编译 时 将 其 指 癌 本 机 的 jdk 路 径 即 可 。 而 


libjni-test.so 则 是 生成 的 so 库 的 名 字 ， 在 Java 中 可 以 通过 如 下 方式 加 
载 : System.loadLibrary("jni-test")， 其 中 so 库 名 字 中 的 lib” 和 “.so” 是 不 
需要 明确 指出 的 。so 库 编译 完成 后 ， 融 可 以 在 Java 程 序 中 调用 so 库 
了 ， 这 里 通过 Java 指 令 来 执行 Java 程 序 ， 切 换 到 主 目 永 ， 执 行 如 下 指 
令 : java -Djava.library.path=jni com.ryg.JniTest , 其 中- 


Djava.library.path=jni 指 明了 so 库 的 路 径 。 


首先 ， 采 用 C++ 产生 so 库 ， 程 序 运 行 后 产生 的 日 志 如 下 所 示 。 


invoke get in c++ 
Hello from JNI ! 
invoke set from C++ 


hello world 


然后 ， 采 用 C 产 生 so 库 ， 程 序 运 行 后 产生 的 日 志 如 下 所 示 。 


invoke get from C 
Hello from JNI ! 
invoke set from C 


hello world 


通过 上 面 的 日 志 可 以 发 现 ， 在 Java 中 成 功 地 调用 了 C/C++ 的 代码 ， 
这 束 是 JNI 典 型 的 工作 流程 。 


14.2 ”NDK 的 开发 流程 


NDK 的 开发 是 基于 JNI 的 ， 其 主要 由 如 下 几 个 步骤 。 


1. 下 载 并 配置 NDK 


首先 要 从 Android E W E FR NDK, FR HHHK 
https://developer.android.com/ndk/downloads/index.html, 7S Æ 7% H AY) 
NDK 的 版 本 是 android-ndk-r10d。 下 载 完成 以 后 ， 将 NDK 解 压 到 一 个 目 
录 ， 然 后 为 NDK 配 置 环境 变量 ， 步 又 如 下 所 示 。 


目 先 打开 当前 用 户 的 环境 变量 配置 文件 : 


vim -/.bashrc 


然后 在 文件 后 面 添 加 如 下 信息 : export PATH=~/Android/android- 
ndk-r10d:$sPATH， 其 中 ~/Android/android-ndk-r10d 是 本 地 的 NDK 的 存放 
BATE ° 


添加 完毕 后 ， 执 行 source ~/.bashrc 来 立刻 刷新 刚刚 设置 的 环境 变 
量 。 设 置 完 环境 变量 后 ，ndk-build 命 令 就 可 以 使 用 了 ， 通 过 ndk-build 
命令 就 可 以 编译 产生 so 库 。 


2. 创建 一 个 Android 项 目 ， 并 声明 所 需 的 native 方 法 


package com.ryg.JniTestApp; 

import android.support.v7.app.ActionBarActivity; 
import android.os.Bundle; 

import android.util.Log; 

import android.view.Menu; 

import android.view.Menultem; 

import android.widget.TextView; 


public class MainActivity extends ActionBarActivity { 


3. 实现 Android 项 目 中 所 声明 的 native 方 法 


在 外 部 创建 一 个 名 为 jni 的 目录 ， 然 后 在 jni 目 录 下 创建 3 个 文件 : 
test.cpp、Android.mk 和 Application.mk， 它 们 的 实现 如 下 所 示 。 


#Unless required by applicable law or agreed to in 
writing, software 
#distributed under the License is distributed on an "AS 
IS" BASIS, 
#WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either 
express or implied. 
#See the License for the specific language governing 
permissions and 
#limitations under the License. 
# 
LOCAL_PATH := $(call my-dir) 
include $(CLEAR_VARS) 
LOCAL_MODULE := jni-test 
LOCAL_SRC_FILES := test.cpp 
include $(BUILD_SHARED_LIBRARY ) 
// Application.mk 


APP_ABI := armeabi 


ix E Xf Android.mk 和 Application.mk 做 一 下 人 简单 的 介绍 。 在 
Android.mk 中 ， LOCAL MODULE 表示 模块 的 名 称 ， 
LOCAL_SRC_FILES 表 示 需 要 参与 编译 的 源 文件 。Application.mk 中 常 
用 的 配置 项 是 APP_ABI， 它 表示 CPU 的 架构 平台 的 类 型 ， 目 前 市 面 上 
EET N 、x86 和 mips， 其 中 在 移动 设备 中 占据 主要 
地 位 的 是 armeabi， 这 也 是 大 部 分 apk 中 只 包 仿 armeabi 类 型 的 so 库 的 原 
因 。 默 认 情 况 下 NDK 会 编译 产生 各 个 CPU 平台 的 so 库 ， 通 过 APP_ABI 


选项 即 可 指定 so 库 的 CPU 平台 的 类 型 ， 比 如 armeabi， 这 样 NDK 就 只 会 
编译 armeabi 平 台 下 的 so 库 了 ， 而 电 则 表示 编译 所 有 CPU 平台 的 so 库 。 


4. 切换 到 jni 目 录 的 父 目 录 ， 然 后 通过 ndk-build 命 令 编译 产生 so 库 


这 个 时 候 NDK 会 创建 一 个 和 jni 目 录 平 级 的 目录 libs，libs 下 面 存放 
的 就 是 so 库 的 目录 ， 如 图 14-1 所 示 。 需 要 注意 的 是 ，ndk-build 命 令 会 
默认 指定 jni 目 录 为 本 地 源码 的 目录 ， 如 果 源 码 存放 的 目录 名 不 是 jni， 
那么 ndk-build 则 无 法 成 功 编译 。 
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图 14-1 通过 NDK 编 译 产 生 的 so 库 


然后 在 app/srcmain 中 创建 一 个 名 为 jniLibs 的 目录 ， 将 生成 的 so 库 
复制 到 jniLibs 目 7 中 ， 然 后 通过 AndroidStudio 编 译 运 行 即 可 ， 运 行 效 
果 如 图 14-2 所 示 。 这 说 明 从 Android 中 调用 so 库 中 的 方法 已 经 成 功 了 。 


JniTestApp 


Hello from JNI in libjri-test.so ! 


库 中 的 方法 示例 


口 


图 14-2 Android ii HAs 


在 上 面 的 步骤 中 ， 需 要 将 NDK 编 译 的 so 库 放 置 到 jniLibs 目 孙 下 ， 
这 个 是 AndroidStudio 所 识别 的 默认 目 孙 ， 如 果 想 使 用 其 他 目 孙 ， 可 以 
按照 如 下 方式 修改 App 的 build.gradle 文 件 ， 其 中 jniLibs.srcDir 选 项 指定 
了 新 的 存放 so 库 的 目录 。 


android { 


sourceSets.main { 


jniLibs.srcDir 'src/main/jni_libs' 


} 


除了 手动 使 用 ndk-build 命 令 创 建 so 库 ， 还 可 以 通过 AndroidStudio 
来 目 动 编译 产生 so 库 ， 这 个 操作 过 程 要 稍微 复杂 一 些 。 为 了 能 够 让 
AndroidStudio 目 动 编译 JNI 代 码 ， 首 先 需 要 在 App 的 build.gradle 的 
defaultConfig 区 域内 添加 NDK 选 项 ， 其 中 moduleName 指 定 了 模块 的 名 
称 ， 这 个 名 称 指 定 了 打包 后 的 so 库 的 文件 名 ， 如 下 所 示 。 


接着 需要 将 JNI 的 代码 放 在 app/src/main/jni 目 录 下 ， 注 意 存放 JNI 代 
码 的 目录 名 必须 为 jni， 如 果 不 想 采 用 jni 这 个 名 称 ， 可 以 通过 如 下 方式 
来 指定 JNI 的 代码 路 径 ， 其 中 jni.srcDirs 指 定 了 JNI 代 码 的 路 径 : 


经 过 了 上 面 的 步骤 ，Androidstudio 就 可 以 自动 编译 JNI 代 码 了 ， 但 
是 这 个 时 候 AndroidStudio 会 把 所 有 CPU 平台 的 so 库 都 打包 到 apk 中 ， 一 
般 来 说 实际 开发 中 只 需要 打包 armeabi 平 台 的 so 库 即 可 。 要 解决 这 个 问 


题 也 很 简单 ， 按 照 如 下 方式 修改 build.gradle 的 配置 ， 然 后 在 Build 
Variants 面 板 中 选择 armDebug 选 项 进行 编辑 束 可 以 了 。 


如 图 14-3 所 示 ， 可 以 看 到 apk 中 了 台 只 有 armeabi 平 台 的 so 库 了 > 


app-arm-debug.apk 


T A 位 置 (L) : al /lib/anmeabi/ 


, Als u DER 
libjnitest.so 9.4 KB 共享 库 2015F5A298 15:35 


1 个 对象 (9.4 KB) 


图 14-3 ”AndroidStudio 打 包 后 的 apk 


14.3 JNI 的 数据 类 型 和 类 型 签名 


JNI 的 数据 类 型 包含 两 种 : 基本 类 型 和 引用 类 型 。 基 本 类 型 主要 有 
jboolean > jchar 、jint 等 ， 它 们 和 Java 中 的 数据 类 型 的 对 应 关系 如 表 14-1 
所 示 。 


表 14-1 JNI 基 本 数据 类 型 的 对 应 关系 


INI 类 型 


Java 类 型 


jboolean 


boolean 


jbyte byte 


jshort 


short 


:符号 16 位 整 型 


有 符 


号 16 位 整 型 


Jint 


int 


32 位 整 型 


jlong 


long 


64 位 整 型 


jfloat 


float 


32 位 浮 点 型 


jdouble 


double 


64 位 浮 点 型 


void 


JNI 中 的 引用 类 型 主要 有 类 、 对 象 和 数组 ， 它 们 和 Java 中 的 引用 类 


型 的 对 应 关系 如 表 14-2 所 示 。 


JNI 类 型 


void 


表 14-2 JNI3 引 


Java 类 型 


类 型 的 对 应 关系 


无 类 型 


CES 


jobject 


jclass 


Object 


Class 


Object 类 型 


Class 类 型 


jstring 


String 


FRR 


jobjectArray 


jbooleanArray 


jbyteArray 


Object[] 
boolean[] 


byte[] 


NRA 
boolean X? 


byte 数组 


jcharArray 


char[] 


char 数组 


jshortArray 


short[] 


short 数组 


jintArray 


int[] 


int 24 


jlongArray 


long[] 


long 21% 


jfloatArray 


jdoubleArray 


float[] 


double[] 


float #4 


double 数组 


jthrowable 


JNI 的 类 型 等 名 标识 了 一 个 特定 的 Java 类 型 ， 这 个 类 型 既 可 以 是 类 


和 方法 ， 也 可 以 是 数据 类 型 。 


类 的 签名 比较 简单 ， 它 采用 和 拒 + 包 和 名 + 类 名 +;” 的 形式 ， 只 需要 将 其 
中 的 .替换 为 / 即 可 。 比 如 javalang.String , 


Throwable 


Throwable 


Ljava/lang/String;， 注 意 末 尾 的 ;也 是 签名 的 一 部 分 。 


EW a 4 A 


基本 数据 类 型 的 签名 采用 一 系列 大 写字 母 来 表示 ， 如 表 14-3 所 


表 14-3 ”基本 数据 类 型 的 签名 


从 表 14-3 可 以 看 出 ， 基 本 数据 类 型 的 签名 是 有 规律 的 ， 一 般 为 首 
字母 的 大 写 ， 但 是 boolean 除 外 ， 因 为 B 已 经 被 byte 占 用 了 ， 而 long 的 签 
名 之 所 以 不 是 L， 那 是 因为 上 表示 的 是 类 的 签名 。 


对 象 和 数组 的 签名 稍微 复杂 一 些 。 对 于 对 象 来 说 ， 它 的 签名 束 是 
对 象 所 属 的 类 的 签名 ， 比 如 String 对象 ， 它 的 签名 为 
Ljava/lang/String;。 对 于 数组 来 说 ， 它 的 签名 为 [+ 类 型 签名 ， 比 如 int 数 
组 ， 其 类 型 为 int， 而 int 的 签名 为 1， 所 以 int 数 组 的 签名 束 是 [I， 同 理 吏 
可 以 得 出 如 下 的 签名 对 应 关系 : 


char[ ] [C 
float[] [F 
double[ ] [D 
long[ ] [J 
String[ ] [Ljava/lang/String; 
Object ] [Ljava/lang/Object; 


对 于 多 维 数组 来 说 ， 它 的 签名 为 n 个 [+ 类 型 签名 ， 其 中 n 表 示 数 组 
的 维度 ， 比 如 ，int[]0 的 签名 为 [[I， 其 他 情况 可 以 依 此 类 推 。 


方法 的 签名 为 (参数 类 型 签名 ) + 返回 值 类 型 签名 ， 这 有 点 不 好 
理解 。 举 个 例子 ， 如 下 方法 : boolean fun1(int a,double b,int[] c)， 根 据 
签名 的 规则 可 以 知道 ， 它 的 参数 类 型 的 签名 连 在 一 起 是 ID[II， 返 回 值 
类 型 的 签名 为 2， 所 以 整个 方法 的 签名 丈 是 IDIDZ。 再 举 个 例 于 ， 下 
面 的 方法 : boolean funl(int a,String b inĝ c)， 它 的 签名 是 
(ILjava/lang/String;[DZ。 为 了 能 够 更 好 地 理解 方法 的 签名 格式 ， 下 面 
再 给 出 两 个 示例 : 


int fun1() 签名 为 ()I 
void fun1(int i) 签名 为 (I)V 


14.4 JNI 调 用 Java 方 法 的 流程 


JNI 调 用 Java 方 法 的 流程 是 先 通 过 类 名 找到 类 ， 然 后 再 根据 方法 名 
找到 方法 的 d， 最 后 束 可 以 调用 这 个 方法 了 。 如 采 是 调用 Java 中 的 非 
静态 方法 ， 那 么 需要 构造 出 类 的 对 象 后 才能 调用 它 。 下 面 的 例子 演示 
了 如 何在 JNI 中 调用 Java 的 静态 方法 ， 至 于 调用 非 静 态 方 法 只 是 多 了 一 
步 构造 对 象 的 过 程 ， 这 里 吏 不 再 介绍 了 。 


首先 需要 在 Java 中 定义 一 个 静态 方法 供 JNI 调 用 ， 如 下 所 示 。 


public static void methodCalledByJni(String msgFromJni) { 
Log.d(TAG, "methodCalledByJni,msg: " + msgFromJni); 
} 


然后 在 JNI 中 调用 上 面 定义 的 静态 方法 : 


void callJavaMethod(JNIEnv *env, jobject thiz) { 
jclass clazz = env- 
>FindClass("com/ryg/JniTestApp/MainActivity"); 
if (clazz == NULL) { 
printf("find class MainActivity error!"); 


return; 


jmethodID id = env- 
>GetStaticMethodID(clazz, "methodCalledByJni", 
"(Ljava/lang/String; )V"); 
if (id == NULL) { 


printf("find method methodCalledByJni error!"); 


jstring msg = env->NewStringUTF("msg send by 
callJavaMethod in 
test.cpp."); 


env->CallStaticVoidMethod(clazz,id,msg); 


从 callJavaMethod 的 实现 可 以 看 出 ， 程 序 首 先 根 据 类 名 
com/ryg/JniTestApp/MainActivity 找 到 类 ， 然 后 再 根据 方法 名 
methodCalledByJni 找到 方法 ， 其 中 (Ljava/lang/String;)V 是 
methodCalledByJni 方法 的 签名 ， 接 着 再 通过 JNIEnv 对象 的 
CallStaticVoidMethod 方 法 来 完成 最 终 的 调用 过 程 。 


最 后 在 Java_com_ryg_JniTestApp_MainActivity_get 方法 中 调用 
callJavaMethod 方 法 ， 如 下 所 示 。 


jstring Java_com_ryg_JniTestApp_MainActivity_get(JNIEnv 
*env, jobject thiz){ 
printf("invoke get in c++\n"); 
callJavaMethod(env,thiz); 
return env->NewStringUTF("Hello from JNI in libjni- 
test.so !"); 


i 


由 + MainActivity 2 WW 用 N 中 的 
Java_com_ryg_JniTestApp_MainActivity_get 方 法 ， 
Java_com_ryg_JniTestApp_MainActivity_get 7 法 又 会 WA 用 
callJavaMethod 方法 ， 而 callJavaMethod 方 法 又 会 反 过 来 调用 
MainActivity 的 methodCalledByJni 方 法 ， 这 样 一 来 就 完成 了 一 次 从 Java 
调用 JNI 然 后 再 从 JNI 中 调用 Java 方 法 的 过 程 。 安 装运 行程 序 ， 可 以 看 
到 如 下 日 志 ， 这 说 明 程序 已 经 成 功 地 从 JNI 中 调用 了 Java 中 的 
methodCalledByJni 方 法 。 


D/MainActivity: methodCalledByJni,msg: msg send by 


callJavaMethod in test.cpp. 


我 们 可 以 发 现 ，JNI 调 用 Java 的 过 程 和 Java 中 方法 的 定义 有 很 大 关 
联 ， 针 对 不 同类 型 的 Java 方 法 ，JNIEnv 提 供 了 不 同 的 接口 去 调用 ， 本 
章 作 为 一 个 JNI 的 入 门 章节 就 不 再 对 它们 一 一 进行 介绍 了 ， 上 毕竟 大 部 分 
应 用 层 的 开发 人 员 并 不 需要 那么 深入 地 了 解 JNI， 如 果 读 者 感 兴趣 可 以 
自行 阅读 相关 的 JNI 专 业 书 籍 。 


第 15 章 Android 性 能 优化 


本 章 是 本 书 的 最 后 一 章 ， 所 介绍 的 主题 是 Android 的 性 能 优化 方法 
和 程序 设计 的 一 些 思 想 。 通 过 本 章 的 内 容 ， 读 者 可 以 掌握 常见 的 性 能 
优化 方法 ， 这 将 有 助 于 提高 Android 程 序 的 性 能 ， 男 一 方面 ， 本 章 还 讲 
解 了 Android 程 序 设计 的 一 些 思想 ， 这 将 有 助 于 提高 程序 的 可 维护 性 和 
可 扩展 性 。 另 外 ，2015 年 Google 在 YouTube 上 发 布 了 关于 Android 性 能 
优化 典范 的 专题 ， 通 过 一 系列 短视 频 来 帮助 开发 者 创建 更 快 更 优秀 的 
Android 应 用 ， 课 程 专题 不 仅仅 介绍 了 Android 系 统 中 有 关 性 能 问题 的 
底层 工作 原理 ， 同 时 也 介绍 了 如 何 通过 工具 来 找 出 性 能 问题 以 及 提升 
性 能 的 建议 ， 地 址 是 : 


https://www.youtube.com/playlist? 
list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE ° 


Android 设 备 作 为 一 种 移动 设备 ， 不 管 是 内 存 还 是 CPU 的 性 能 都 受 
到 了 一 定 的 限制 ， 无 法 做 到 像 PC 设 备 那 样 具 有 超大 的 内 存 和 高 性 能 的 
CPU。 鉴 于 这 一 点 ， 这 也 意味 着 Android 程 序 不 可 能 无 限制 地 使 用 内 存 
和 CPU 资源 ， 过 多 地 使 用 内 存 会 导致 程序 内 存 洪 出 ， 即 OOM。 而 过 多 
地 使 用 CPU 资源 ， 一 般 是 指 做 大 量 的 耗 时 任务 ， 会 导致 手机 变 得 卡 顿 
甚至 出 现 程序 无 法 响应 的 情况 ， 即 ANR。 由 此 来 看 ，Android 程 序 的 性 
能 问题 就 变 得 异常 突出 了 ， 这 对 开发 人 员 也 提出 了 更 高 的 要 求 。 为 了 
提高 应 用 程序 的 性 能 ， 本 章 第 一 市 介绍 了 一 些 有 效 的 性 能 优化 方法 ， 
主要 内 容 包 括 布局 优化 、 绘 制 优 化 、 内 存 泄露 优化 、 啊 应 速度 优化 、 


ListView 优 化 、Bitmap 优 化 、 线 程 优 化 以 及 一 些 性 能 优化 建议 ， 同 时 
在 介绍 啊 应 速度 优化 的 同时 还 介绍 了 ANR 日 志 的 分 析 方 法 。 


性 能 优化 中 一 个 很 重要 的 问题 束 古 内 存 泄露 ， 内 存 泄露 并 不 会 寻 
致 程序 功能 异常 ， 但 是 它 会 导致 Android 程 序 的 内 存 占用 过 大 ， 这 将 提 
高 内 存 盗 出 的 发 生 几 率 。 如 何 避 免 写 出 内 存 泄 露 的 代码 ， 这 和 开发 人 
员 的 水 平和 意识 有 很 大 关系 ， 甚 至 很 多 情况 下 内 存 泄露 的 原因 古 很 难 
直接 发 现 的 ， 这 个 时 候 就 需要 借助 一 些 内 存 泄露 分 析 工 具 ， 在 本 章 的 
第 二 节 将 介绍 内 存 泄 露 分 析 工 具 MAI 的 使 用 ， 通 过 MAT 就 可 以 发 现 一 
些 开发 过 程 中 难以 发 现 的 内 存 泄露 问题 。 


在 做 程序 设计 时 ， 除 了 要 完成 功能 开发 、 提 高 程序 的 性 能 以 外 ， 
还 有 一 个 问题 也 十 不 容 忽视 的 ， 那 束 是 代码 的 可 维护 性 和 可 扩展 性 。 
如 果 一 个 程序 的 可 维护 性 和 可 扩展 性 很 莽 ， 那 整 意 味 着 后 续 的 代码 维 
护 代 价 是 相当 高 的 ， 比 如 需要 对 一 个 功能 做 一 些 调整 ， 这 可 能 会 出 现 
率 一 发 而 动 全 里 的 局 面 。 男 外 添加 新 功能 时 也 觉得 无 从 下 手 ， 整 个 代 
码 看 起 来 可 读 性 很 过， 这 的 确 是 一 份 很 糟糕 的 代码 。 关 于 代码 的 可 维 
护 性 和 可 扩展 性 ， 看 起 来 是 一 个 很 抽象 的 问题 ， 其 实 它 并 不 抽象 ， 它 
征 可 以 通过 一 些 合理 的 设计 原则 去 完成 的 ， 比 如 民 好 的 代码 风格 、 请 
晰 的 代码 层级 、 代 码 的 可 扩展 性 和 合理 的 设计 模式 ， 在 本 章 的 第 三 节 
对 这 些 设计 原则 做 了 介绍 ， 这 将 在 一 定 程度 上 提高 程序 的 可 维护 性 和 
可 扩展 性 。 


15.1 Android 的 性 能 优化 方法 


本 下 介绍 了 一 些 有 效 的 性 能 优化 方法 ， 主 要 内 容 包 括 布局 优化 、 
绘制 优化 、 内 存 泄露 优化 、 啊 应 速度 优化 、ListView 优 化 、Bitmap 优 


化 、 线 程 优 化 以 及 一 些 性 能 优化 建议 ， 在 介绍 啊 应 速度 优化 的 同时 还 
介绍 了 ANR 日 志 的 分 析 方 法 。 


15.1.1 布局 优化 


布局 优化 的 思想 很 简单 ， 束 是 尽量 减少 布局 文件 的 层级 ， 这 个 道 
理 钙 很 浅显 的 ， 布 局 中 的 层级 少 了 ， 这 束 意 味 着 Android 绘 制 时 的 工作 
量 少 了 ， 那 么 程序 的 性 能 目 然 束 高 了 。 


如 何 进 行 布局 优化 呢 ? 首 先 删除 布局 中 无 用 的 控件 和 层级 ， 其 次 
有 选择 地 使 用 性 能 较 低 的 ViewGroup ， 比 如 RelativeLayout。 如 果 布 局 
中 既 可 以 使 用 LinearLayout 也 可 以 使 用 RelativeLayout ， 那 么 瓯 采用 
LinearLayout， 这 是 因为 RelativeLayout 的 功能 比较 复杂 ， 它 的 布局 过 
程 需要 花费 更 多 的 CPU 时 间 。FrameLayout 和 LinearLayout 一 样 都 是 一 
种 简单 高 效 的 ViewGroup ， 因 此 可 以 考虑 使 用 它们 ， 但 是 很 多 时 候 单 
纯 通 过 一 个 LinearLayout 或 者 FrameLayout 无 法 实现 产品 效果 ， 需 要 通 
过 瞬 套 的 方式 来 完成 。 这 种 情况 下 还 是 建议 采用 RelativeLayout， 因 为 
ViewGroup 的 和 藤 套 就 相当 于 增加 了 布局 的 层级 ， 同 样 会 降低 程序 的 性 


AB 
BE ° 


布局 优化 的 另外 一 种 手段 是 采用 <include> 标 答 、<merge> 标 签 和 
ViewStub ° <include> 标 签 主 要 用 于 布局 重用 ，<merge> 标 签 一 般 和 
<include> 配 合 使 用 ， 它 可 以 降低 减少 布局 的 层级 ， 而 ViewStub 则 提供 
了 按 需 加 载 的 功能 ， 当 需要 时 才 会 将 ViewStub 中 的 布局 加 载 到 内 存 ， 
这 提高 了 程序 的 初始 化 效率 ， 下 面 分 别 介绍 它们 的 使 用 方法 。 


<include> 标 签 


<include> 标 签 可 以 将 一 个 指定 的 布局 文件 加 载 到 当前 的 布局 文件 
A 


<LinearLayout 
xmins:android="http://schemas.android.com/apk/res/android" 
android: orientation="vertical" 
android: Layout_width="match_parent" 
android: Llayout_height="match_parent" 
android: background="@color/app_bg" 


android: gravity="center_horizontal"> 
<include layout="@layout/titlebar"/> 


<TextView android: layout_width="match_parent" 
android: Llayout_height="wrap_content" 
android: text="@string/text" 


android: padding="5dp" /> 


</LinearLayout> 


上 面 的 代码 中 ，@layouttitlebar 指 定 了 另外 一 个 布局 文件 ， 通 过 这 
种 方式 瓯 不 用 把 titlebar 这 个 布局 文件 的 内 容 再 重复 写 一 过 了， ne 
<include> 的 好 处 。<include> 标 签 只 文 持 以 android:layout_ 开头 的 属性 ， 
tt UH android:layout_width 、android:layout_height， 其 他 属性 是 不 文 持 
的 ， 比 如 android:background。 当然 ，android:id 这 个 属性 是 个 特例 ， 如 
果 <include> 指 定 了 这 个 id 属 性 ， 同 时 被 包含 的 布局 文件 的 根 元 素 也 指 
定 了 id 属性 ， 那 么 以 <include> 指 定 的 id 属性 为 准 。 需 要 注意 的 是 ， 如 


果 <include> 标签 指定 了 android:layout* 这 种 属性 ， 那 么 要求 
android:layout_width 和 android:layout_height VA FF, EINE Ab 
android:layout * 形 式 的 属性 无 法 生效 ， 下 面 是 一 个 指定 了 
android:layout_* 属 性 的 示例 。 


<include android:id="@+id/new_title" 
android: Layout_width="match_parent" 
android: Llayout_height="match_parent" 


layout="@layout/title"/> 
<merge> 标 签 


<merge> 标 签 一 般 和 <include> 标 签 一 起 使 用 从 而 减少 布局 的 层 
级 。 在 上 面 的 示例 中 ， 由 于 当前 布局 是 一 个 竖 直 方 同 的 LinearLayout， 
这 个 时 候 如 有 果 被 包含 的 布局 文件 中 也 采用 了 竖 直 方 同 的 LinearLayout， 
那么 显然 被 包含 的 布局 文件 中 的 LinearLayout 是 多 余 的 ， 通 过 <merge> 
标签 项 可 以 去 掉 多 余 的 那 一 层 LinearLayout， 如 下 所 示 。 


<merge 
xmins:android="http://schemas.android.com/apk/res/android"> 
<Button 
android: Layout_width="wrap_content" 
android: Llayout_height="wrap_content" 
android: text="@string/one"/> 
<Button 
android: Layout_width="wrap_content" 


android: Llayout_height="wrap_content" 


android: text="@string/two"/> 


</merge> 


ViewStub 


ViewStub4k7K Į View, EFF HERMAN má, NETAS 
不 参与 任何 的 布局 和 绘制 过 程 。ViewStub 的 意义 在 于 按 需 加 载 所 需 的 
布局 文件 ， 在 实际 开发 中 ， 有 很 多 布局 文件 在 正常 情况 下 不 会 显示 ， 
比如 网 络 异 常 时 的 界面 ， 这 个 时 候 就 没有 必要 在 整个 界面 初始 化 的 时 


候 将 其 加 载 进来 ， 


通过 ViewStub 就 可 以 做 到 在 使 用 的 时 候 再 加 载 ， 提 


高 了 程序 初始 化 时 的 性 能 。 下 面 是 一 个 ViewStub 的 示例 : 


<ViewStub 


android: 
android: 
android: 
android: 
android: 


android: 


id="@+id/stub_import" 
inflatedId="@+id/panel_import" 
layout="@layout/layout_network_error" 
layout_width="match_parent" 
layout_height="wrap_content" 


layout_gravity="bottom" /> 


其 中 stub import 是 ViewStub AY id , 而 panel_import 是 
layout/layout_network_error 这 个 布局 的 根 元 素 的 id。 如 何 做 到 按 需 加 载 
We? 在 需要 加 载 ViewStub 中 的 布局 时 ， 可 以 按照 如 下 两 种 方式 进行 


((ViewStub) 


findViewById(R.id.stub_import)).setVisibility(View.VISIBLE); 


或 者 


View importPanel = ((ViewStub) 


findViewById(R.id.stub_import)).inflate(); 


当 ViewStub 通 过 setVisibility 或 者 inflate 方 法 加 载 后 ，ViewStub 束 会 
被 它 内 部 的 布局 替换 抒 ， 这 个 时 候 ViewStub 束 不 再 是 整个 布局 结构 中 
的 一 部 分 了 。 另 外 ， 目 前 ViewStub 还 不 支持 <merge> 标 签 。 


15.1.2 ”绘制 优化 


绘制 优化 是 指 View 的 onDraw 方 法 要 避免 执行 大 量 的 操作 ， 这 主要 
体现 在 两 个 方面 。 


首先 ，onDraw 中 不 要 创建 新 的 局 部 对 象 ， 这 是 因为 onDraw 方 法 可 
能 会 被 频繁 调用 ， 这 样 就 会 在 一 瞬间 产生 大 量 的 临时 对 象 ， 这 不 仪 占 
用 了 过 多 的 内 存 而 且 还 会 导致 系统 更 加 频繁 gc， 降 低 了 程序 的 执行 效 
Ro 


另外 一 方面 ，onDraw 方 法 中 不 要 做 耗 时 的 任务 ， 也 不 能 执行 成 千 
上 万 次 的 循环 操作 ， 尽 管 on. 级 ， 但 是 大 量 的 循环 仍然 
十 分 抢占 CPU 的 时 间 片 ， 这 会 造成 View 的 绘制 过 程 不 流畅 。 按 照 
Google E F724 HATER e 中 的 标准 ，View 的 绘制 帧 率 保证 60fps 
是 最 佳 的 ， 这 就 要 求 每 帧 的 绘制 时 间 不 超过 16ms (16ms = 1000 / 
60) ， 虽 然 程 序 很 难保 证 16ms 这 个 时 间 ， 但 是 尽量 降低 onDraw 方 法 的 
复杂 度 总 是 切实 有 效 的 。 


15.1.3 ”内 存 泄露 优化 


内 存 泄 露 在 开发 过 程 中 是 一 个 需要 重视 的 问题 ， 但 是 由 于 内 存 泄 
露 问题 对 开发 人 员 的 经 验 和 开发 意识 有 较 高 的 要 求 ， 因 此 这 也 是 开发 
员 最 容易 犯 的 错误 之 一 。 内 存 泄露 的 优化 分 为 两 个 方面 ， 一 方面 是 
在 开发 过 程 中 避免 写 出 有 内 存 泄露 的 代码 ， 男 一 方面 是 通过 一 些 分 析 
工具 比如 MAT 来 找 出 潜在 的 内 存 泄 露 继而 解决 。 本 广 主要 介绍 一 些 常 
见 的 内 存 泄露 的 例子 ， 通 过 这 些 例子 读者 可 以 很 好 地 理解 内 存 泄 露 的 
发 生 场 景 并 积累 规避 内 存 泄 露 的 经 验 。 关 于 如 何 通过 工具 分 析 内 存 泄 
露 将 在 15.2 节 中 专门 介绍 。 


场景 1: 静态 变量 导致 的 内 存 泄露 


下 面 这 种 情形 是 一 种 最 简单 的 内 存 泄露 ， 相 信 读 者 都 不 会 这 么 
于 ， 下 面 的 代码 将 导致 Activity 无 法 正 彰 销毁 ， 因 此 静态 变量 SContext 
引用 了 它 。 


public class MainActivity extends Activity { 
private static final String TAG = "MainActivity"; 
private static Context sContext; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


sContext = this; 


} 


上 面 的 代码 也 可 以 改造 一 下 ， 如 下 所 示 。sView 是 一 个 静态 变量 ， 
它 内 部 持 有 了 当前 Activity， 所 以 Activity 仍 然 无 法 释放 ， 估 计 读 者 也 


都 明日 。 


public class MainActivity extends Activity { 
private static final String TAG = "MainActivity"; 
private static View sView; 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


sView = new View(this); 


场景 2: 单 例 模式 导致 的 内 存 泄 露 


静态 变量 导致 的 内 存 泄 露 都 太 过 于 明显 ， 相 信 读 者 都 不 会 犯 这 种 
背 误 ， 而 单 例 模 式 所 带 来 的 内 存 泄 露 是 我 们 容易 忽视 的 ， 如 下 所 示 。 
首先 提供 一 个 单 例 模 式 的 TestManager，TestManager 可 以 接收 外 部 的 注 
册 并 将 外 部 的 监听 器 存储 起 来 。 


public class TestManager { 
private List<OnDataArrivedListener> 
mOnDataArrivedListeners = new 
ArrayList<OnDataArrivedListener>(); 
private static class SingletonHolder { 
public static final TestManager INSTANCE = new 


TestManager(); 


} 


接着 再 让 Activity 实 现 OnDataArrivedListener 接 口 并 同 TestManager 
注册 监听 ， 如 下 所 示 。 下 面 的 代码 由 于 缺少 解 注 册 的 操作 所 以 会 引起 
内 存 泄 露 ， 洪 露 的 原因 是 Activity 的 对 象 被 单 例 模式 的 TestManager 所 持 
有 ， 而 单 例 模式 的 特点 是 其 生命 周期 和 Application 保 持 一 致 ， 因 此 
Activity 对 象 无 法 被 及 时 释放 。 


protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


TestManager .getInstance().registerListener(this); 


E ES 


M Android 3.0 开 始 ，Google 提 供 了 属性 动画 ， 属 性 动画 中 有 一 类 
无 限 循环 的 动画 ， 如 果 在 Activity 中 播放 此 类 动画 且 没 有 在 onDestroy 中 
去 停止 动画 ， 那 么 动画 会 一 直播 放下 去 ， 尽 管 已 经 无 法 在 界面 上 看 到 
动画 效果 了 ， 并 且 这 个 时 候 Activity 的 View 会 被 动画 持 有 ， 而 View 又 持 
有 了 Activity， 最 终 Activity 无 法 释放 。 下 面 的 动画 是 无 限 动 画 ， 会 汇 
Be “4 Hl Activity ， 解 决 方法 是 在 Activity 的 onDestroy 中 调用 
animatorcancel(0) 来 停止 动画 。 


protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 
mButton = (Button) findViewById(R.id.button1); 

ObjectAnimator animator = 
ObjectAnimator.ofFloat(mButton, "rotation", 
0,360) .setDuration(2000); 

animator.setRepeatCount (ValueAnimator.INFINITE); 
animator.start(); 


//animator.cancel(); 


de 啊 应 速度 优化 和 ANR HA 


啊 应 速度 优化 的 核心 思想 是 避免 在 主线 程 中 做 耗 时 操作 ， 但 是 有 
时 候 的 确 有 很 多 耗 时 操作 ， 怎 么 办 呢 ? 可 以 将 这 些 耗 时 操作 放 在 线程 
中 去 执行 ， 即 采用 异步 的 方式 执行 耗 时 操作 。 啊 应 速度 过 慢 更 多 地 体 
现在 Activity 的 启动 速度 上 面 ， 如 果 在 主线 程 中 做 太 多 事情 ， 会 导致 
Activity 启 动 时 出 现 黑屏 现象 ， 甚 至 出 现 ANR。Android 规 定 ，Activity 
如 采 5 秒 钟 之 内 无 法 响应 屏 磋 触摸 事件 或 者 键盘 输入 事件 就 会 出 现 
ANR， 而 BroadcastReceiver 如 果 10 秒 钟 之 内 还 未 执行 完 操作 也 会 出 现 
ANR 。 在 实际 开发 中 ，ANR 十 很 难 从 代码 上 发 现 的 ， 如 果 在 开发 过 程 
中 通 到 了 ANR， 那 么 怎么 定位 问题 呢 ? 其 实 当 一 个 进程 发 生 ANRT 了 以 
后 ， 系 统 会 在 /data/anr 目 录 下 创建 一 个 文件 traces.txt， 通 过 分 析 这 个 文 
件 融 能 定位 出 ANR 的 原因 ， 下 面 模拟 一 个 ANR 的 场景 。 下 面 的 代码 在 
Activity 的 onCreate 中 休眠 30s， 程 序 运行 后 持续 点 击 屏幕 ， 应 用 一 定 会 
出 现 ANR: 


protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


SystemClock.sleep(30 * 1000); 


这 里 先 假定 我 们 无 法 从 代码 中 看 出 ANR， 为 了 分 析 ANR 的 原因 ， 
可 以 到 处 traces 文 件 ， 如 下 所 示 ， 其 中 .表示 当前 目 邓 : 


adb pull /data/anr/traces.txt . 
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traces 文 件 一 般 是 非常 长 的 ， 下 面 是 traces 文 件 的 部 分 内 容 : 


=> pid 29395 at 2015-05-31 16:14:36 ----- 
Cmd line: com.ryg.chapter_15 
DALVIK THREADS: 
(mutexes: tl11=0 tsl=0 tscl=0 ghl1=0) 
"main" prio=5 tid=1 TIMED_WAIT 
| group="main" sCount=1 dsCount=0 obj=0x4185b700 
self=0x4012d0b0 
| sysTid=29395 nice=0 sched=0/0 cgrp=apps 
handle=1073954608 
| schedstat=( 0 0 © ) utm=3 stm=2 core=2 
at java.lang.VMThread.sleep(Native Method) 
at java.lang.Thread.sleep(Thread.java:1031) 
at java.lang.Thread.sleep( Thread. java:1013) 
at android.os.SystemClock.sleep(SystemClock.java:114) 
at 
com.ryg.chapter_15.MainActivity.onCreate(MainActivity. java: 42) 
at 
android.app.Activity.performCreate(Activity. java:5086) 
at 
android.app.Instrumentation.callActivityOnCreate(Instrumentatio 
n.java:1079) 
at 
android.app.ActivityThread.performLaunchActivity(ActivityThread 
.Java:2056) 


at 


android.app.ActivityThread.handleLaunchActivity(ActivityThread. 
java:2117) 
at 
android.app.ActivityThread.access$600(ActivityThread.java:140) 
at 
android.app.ActivityThread$H.handleMessage(ActivityThread.java: 
1213) 
at android.os.Handler.dispatchMessage(Handler.java:99) 
at android.os.Looper.loop(Looper.java:137) 
at 
android.app.ActivityThread.main(ActivityThread.java:4914) 
at java.lang.reflect.Method.invokeNative(Native Method) 
at java.lang.reflect.Method.invoke(Method.java:511) 
at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(Zygo 
teInit.java:808) 
at 
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:575) 
at dalvik.system.NativeStart.main(Native Method) 
"Binder_2" prio=5 tid=10 NATIVE 
| group="main" sCount=1 dsCount=0 obj=0x42296d80 
self=0x69068848 
| sysTid=29407 nice=® sched=0/0 cgrp=apps 
handle=1750664088 
| schedstat=( 0 0 © ) utm=0 stm=0 core=1 
#00 pc 0000cc50 /system/lib/libc.so (__ioct1+8) 
#01 pc 0002816d /system/lib/libc.so (ioct1l+16) 


#02 pc 00016f9d /system/lib/libbinder.so 
(android: :IPCThreadState::talkwithDriver(bool)+124) 
#03 pc 0001768f /system/lib/libbinder.so 
(android: :IPCThreadState: :joinThreadPool(bool)+154) 
#04 pc 0001b4e9 /system/lib/libbinder.so 
#05 pc 00010f7f /system/lib/libutils.so 
(android: : Thread: :_threadLoop(void* )+114) 
#06 pc 00048ba5 /system/lib/libandroid_runtime.so 
(android: :Android-Runtime: :javaThreadShell(void*)+44) 
#07 pc 00010ae5 /system/lib/libutils.so 
#08 pc 0e012ffo /system/lib/libc.so 
(__thread_entry+48) 
#09 pc 00012748 /system/lib/libc.so 
(pthread_create+172) 


at dalvik.system.NativeStart.run(Native Method) 


从 traces 的 内 容 可 以 看 出 ， 主 线程 直接 sleep T, MEAN: 
MainActivityHJ 4247 ° 284247 WI fé SystemClock.sleep(30 * 1000), 
这 样 一 来 就 可 以 定位 问题 了 。 当 然 这 个 例子 太 直接 了 ， 下 面 再 模拟 一 
个 稍微 复杂 点 的 ANR 的 例子 。 


下 面 的 代码 也 会 导致 ANR， 原 因 是 这 样 的 ， 在 Activity 的 onCreate 
中 开启 了 一 个 线程 ， 在 线程 中 执行 testANR()， 而 testANRO 和 initView() 
都 被 加 了 同一 个 锁 ， 为 了 百分之百 让 testANRO 先 获得 锁 ， 特 意 在 执行 
initView() 之 前 让 主线 程 休 卢 了 10ms， 这 样 一 来 initView0 肯 定 会 因为 等 
待 testANRO 所 持 有 的 锁 而 被 同步 住 ， 这 样 就 产生 了 一 个 稍微 复杂 些 的 
ANR。 这 个 ANR 是 很 参考 意义 的 ， 这 样 的 代码 很 容易 在 实际 开发 中 出 


现 ， 尤 其 古 当 调用 关系 比较 复杂 时 ， 这 个 时 候 分 析 ANR 日 志 束 显得 异 
党 重要 了 。 下 面 的 代码 中 虽然 已 经 将 耗 时 操作 放 在 线程 中 了 ， 按 道理 
就 不 会 出 现 ANR 了 ， 但 是 仍然 要 注意 子 线程 和 主线 程 抢 占 同 步 锁 的 情 
Ho 


为 了 分 析 问 题 ， 需 要 从 traces 文 件 着 手 ， 如 下 所 示 。 


(mutexes: tl1=0 tsl=0 tscl=0 ghl1=0) 
"main" prio=5 tid=1 MONITOR 
| group="main" sCount=1 dsCount=0 obj=0x4185b700 
self=0x4012d0b0 
| sysTid=32662 nice=® sched=0/0 cgrp=apps 
handle=1073954608 
| schedstat=( 0 0 © ) utm=0 stm=4 core=0 
at 
com.ryg.chapter_15.MainActivity.initView(MainActivity.java:-62) 
-waiting to lock <0x422a0120> (a 
com.ryg.chapter_15.MainActivity) held 
by tid=11 (Thread-13248) 
at 
com.ryg.chapter_15.MainActivity.onCreate(MainActivity.java:53) 
at 
android.app.Activity.performCreate(Activity.java:5086) 
at 
android.app.Instrumentation.callActivityOnCreate(Instrumentatio 
n.java:1079) 
at 
android.app.ActivityThread.performLaunchActivity(ActivityThread 
.Java:2056) 
at 
android.app.ActivityThread.handleLaunchActivity(ActivityThread. 
java:2117) 
at 


android.app.ActivityThread.access$600(ActivityThread.java:140) 


at 
android.app.ActivityThread$H.handleMessage(ActivityThread.java: 
1213) 
at android.os.Handler.dispatchMessage(Handler.java:99) 
at android.os.Looper.loop(Looper.java:137) 
at 
android.app.ActivityThread.main(ActivityThread.java:4914) 
at java.lang.reflect.Method.invokeNative(Native Method) 
at java.lang.reflect.Method.invoke(Method.java:511) 
at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(Zygo 
teInit.java:808) 
at 
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:575) 
at dalvik.system.NativeStart.main(Native Method) 
"Thread-13248" prio=5 tid=11 TIMED WAIT 
| group="main" sCount=1 dsCount=0 obj=0x422b0ed8 
self=0x683d20c0 
| sysTid=32687 nice=® sched=0/0 cgrp=apps 
handle=1751804288 
| schedstat=( 0 0 © ) utm=0 stm=0 core=0 
at java.lang.VMThread.sleep(Native Method) 
at java.lang.Thread.sleep(Thread.java:1031) 
at java.lang.Thread.sleep(Thread.java:1013) 
at android.os.SystemClock.sleep(SystemClock.java:114) 
at 


com.ryg.chapter_15.MainActivity.testANR(MainActivity.java:57) 


at 
com.ryg.chapter_15.MainActivity.access$0(MainActivity.java:56) 

at 
com.ryg.chapter_15.MainActivity$1.run(MainActivity.java:49) 


at java.lang.Thread.run(Thread.java:856) 


上 面 的 情况 稍微 复杂 一 些 ， 需 要 逐步 分 析 。 首 先 看 主线 程 ， 如 下 
所 示 。 可 以 看 得 出 主线 程 在 initView 方 法 中 正在 等 待 一 个 锁 
<0x422a0120>， 这 个 锁 的 类 型 是 一 个 MainActivity 对 象 ， 并 且 这 个 锁 已 
经 被 线程 id 为 11 ( 即 tid=11) 的 线程 持 有 了 ， 因 此 需要 再 看 一 下 线程 11 
的 情况 。 


at 
com.ryg.chapter_15.MainActivity.initView(MainActivity.java:-62) 
-waiting to lock <0x422a0120> (a 
com.ryg.chapter_15.MainActivity) held 
by tid=11 (Thread-13248) 


tid 是 11 的 线程 就 是 “Thread-13248”， 就 是 它 持 有 了 主线 程 所 需 的 
锁 ， 可 以 看 出 “Thread-13248” 正 在 sleep，sleep 的 原因 是 MainActivity 的 
57 行 ， 即 testANR 方 法 。 这 个 时 候 可 以 发 现 testANR 方 法 和 主线 程 的 
initView 方 法 都 加 了 synchronized 关 键 字 ， 表 明 它 们 在 竞争 同一 个 锁 ， 
即 当 前 Activity 的 对 象 锁 ， 这 样 一 来 ANR 的 原因 就 明确 了 ， 接 着 天 可 以 
修改 代码 了 。 


上 面 分 析 了 两 个 ANR 的 实例 ， 尤 其 是 第 二 个 ANR 在 实际 开发 中 很 
容易 出 现 ， 我 们 首先 要 有 意识 地 避免 出 现 ANR， 其 次 出 现 ANR 了 也 不 
要 着 急 ， 通 过 分 析 traces 文 件 即 可 定位 问题 。 


15.1.5 ListView 和 了 Bitmap 优 化 


ListView 的 优化 在 第 12 章 已 经 做 了 介绍 ， 这 里 再 简单 回顾 一 下 。 
主要 分 为 三 个 方面 : 首先 要 采用 ViewHolder 并 避免 在 getView 中 执行 耗 
时 操作 ， 其 次 要 根据 列表 的 滑动 状态 来 控制 任务 的 执行 频率 ， 比 如 当 
列表 快速 滑动 时 显然 是 不 太 适 合 开启 大 量 的 异步 任务 的 ， 最 后 可 以 党 
试 开启 硬件 加 速 来 使 Listview 的 滑动 更 加 流畅 。 注 意 Listview 的 优化 策 
略 完全 适用 于 GridView。 


Bitmap 的 优化 同样 在 第 12 章 已 经 做 了 详细 的 介绍 ， 主 要 是 通过 
BitmapFactory.Options 来 根据 需要 对 图 片 进 行 采样 ， 采 样 过 程 中 主要 用 
到 了 BitmapFactory.Options 的 inSampleSize 参 数 ， 详 情 这 里 就 不 再 重复 
了 ， 请 参考 第 12 章 的 有 关内 容 。 


15.1.6 ”线程 优化 


线程 优化 的 思想 是 采用 线程 池 ， 避 免 程序 中 存在 大 量 的 Thread。 
线程 池 可 以 重用 内 部 的 线程 ， 从 而 避免 了 线程 的 创建 和 销毁 所 市 来 的 
性 能 开销 ， 同 时 线程 池 还 能 有 效 地 控制 线程 池 的 最 大 并 发 数 ， 避 免 大 
量 的 线程 因 互相 抢占 系统 资源 从 而 导致 阻塞 现象 的 发 生 。 因 此 在 实际 
开发 中 ， 我 们 要 尽量 采用 线程 池 ， 而 不 是 每 次 都 要 创建 一 个 Thread 对 
象 ， 关 于 线程 池 的 详细 介绍 请 参考 第 11 章 的 内 容 。 


15.1.7 一 些 性 能 优化 建议 


ANT IMAM E ERE NAAA E, BUENA LA EE 


。 避免 创建 过 多 的 对 象 ; 

e 不 要 过 多 使 用 枚 举 ， 枚 举 占 用 的 内 存 空间 要 比 整 型 大 ; 

。 销量 请 使 用 static final 来 修饰; 

。 使 用 一 些 Android 特 有 的 数据 结构 ， 比 如 SparseArray 和 Pair 等 ， 它 
们 都 具有 更 好 的 性 能 ; 

。 适当 使 用 软 引 用 和 软 引 用 ; 

© OKRA Ee FAM ME RIT: 

尽量 采用 静态 内 部 类 ， 这 样 可 以 避免 潜在 的 由 于 内 部 类 而 导致 的 


15.2 ”内 存 泄 露 分 析 之 MAT 工 具 


MAT 的 全 称 是 Eclipse Memory Analyzer， 它 是 一 球 强 大 的 内 存 泄 
露 分 析 工 具 ，MAI 不 需要 安装 ， 下 载 后 解压 即 可 使 用 ， 下 载 地 址 为 
http:/www.eclipse.org/mat/downloads.php。 对 于 Eclipse 来 说 ，MAT 也 有 
插件 版 ， 但 是 不 建议 使 用 插件 版 ， 因 为 独立 版 使 用 起 来 更 加 方便 ， 即 
使 不 安装 Eclipse 也 可 以 正常 使 用 ， 当 然 前 提 是 有 内 存 分 析 后 的 hprof 文 
件 。 


为 了 采用 MAI 来 分 析 内 存 泄 露 ， 下 面 模拟 一 种 简单 的 内 存 泄 露 情 
况 ， 下 面 的 代码 肯定 会 造成 内 存 泄露 : 
public class MainActivity extends Activity { 


private static final String TAG = "MainActivity"; 


private static Context sContext; 

@Override 

protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 


sContext = this; 


编译 安装 ， 然 后 打开 DDMS 界 面 ， 其 中 AndroidStudio 的 DDMS 位 
于 Monitor 中 。 接 着 用 鼠标 选中 要 分 析 的 进程 ， 然 后 使 用 竺 分 析 应 用 的 
一 些 功能 ， 这 样 做 是 为 了 将 尽量 多 的 内 存 泄 露 骏 露出 来 ， 然 后 单 击 
Dump HPROF file 这 个 按钮 (对 应 图 15-1 中 底部 有 黑 线 的 按钮 ) ， 等 待 
一 小 段 时 间 即 可 导出 一 个 hprof 后 缀 的 文件 ， 如 图 15-1 所 示 。 


B Devices 2 #180 8 Z| a/a | 
Name 


4 È xiaomi-mi_2-5456024c Online 4.1.1 
com.ryg.chapter_15 4791 8600 / 8700 


图 15-1 DDMS 视 图 


导出 hprof 文 件 后 并 不 能 使 用 它 来 进行 分 析 ， 因 为 它 不 能 被 MAT 直 
接 识 别 ， 需 要 通过 hprof-conv 命 令 转 换 一 下 。hprof-conv 命 令 是 Android 
SDK 提 供 的 工具 ， 它 位 于 Android SDKAYplatform-tools B= F: 


hprof-conv com.ryg.chapter_15.hprof com.ryg.chapter_15- 


conv.hprof 


当然 如 果 使 用 的 是 Eclipse 插件 版 的 MAT 的 话 ， 就 可 以 不 进行 格式 
转换 了 ， 可 以 直接 用 MAT 揪 件 打开 。 


经 过 了 上 面 的 步骤 ， 接 下 来 融 可 以 直接 通过 MAIT 来 进行 内 存 分 析 
了 。 打 开 MAT， 通 过 有 末 单 打开 刚才 转换 后 的 com.ryg.chapter_15- 
conv.hprof 这 个 文件 ， 打 开 后 的 界面 如 图 15-2 所 示 。 


i Overview 33 


~ Biggest Objects by Retained Size 


~ Actions ~ Reports ~ Stop By Step 


ponent Report: Analyze objects which belong 
to a common root package or class loader. 


图 15-2 ”MAT 的 内 存 分 析 主 界面 


如 图 15-2 所 示 ，MAT 提 供 了 很 多 功能 ， 但 是 最 常用 的 只 
Histogram 和 Dominator Tree， 通 过 Histogram 可 以 直观 地 看 出 内 存 中 不 
同类 型 的 buffer 的 数量 和 占用 的 内 存 大 小 ， 而 Dominator Tree 则 把 内 存 
中 的 对 象 按照 从 大 到 小 的 顺序 进行 排序 ， 并 且 可 以 分 析 对 象 之 间 的 引 
用 关系 ， 内 存 泄 露 分 析 就 是 通过 Dominator Tree 来 完成 的 。 图 15-3 和 
15-4 分 别 是 MAT 中 Histogram 和 Dominator Tree 的 界面 。 


8 com.ryg.chapter_15-conv.hprof 3 = 
iaa arar: a > Brae 


| i Overview| lil Histogram £3 | Pg dominator tree, 
Class Name Retained H. 区 
ni nie asin se- i omer 

O bytell 1622 7739128 >= 7,739.1. | 
@ chari] 9,949 553,144 >= 553,144 

@ java.lang.String 11,363 272,712 >= 740,432 | 
© java.util.HashMapSHashMapEntry 5,414 129,936 >= 254,736 | 
@ int 1,869 93872 >= 93,872 

O javallang.Stringí] 1,956 82288 >= 94,488 

© javalang.Class 2,936 71,336 >= 7,456,9.. 

© java.util.HashMapSHashMapEntryl] 255 51,112 >= 308,576 | 
© java.lang.Integer 2,514 40,224 = >= 41,568 上 
© java.lang.Object] 305 21,480 >= 6,359,5.. | 
© java.util HashMap 341 16368 >= 324,648 

© java.utilzip.ZipEntry 224 16128 >= 24,136 

© java.util.Hashtable$HashtableEntry 635 15,240 >= 23,560 

© org.apache.harmony.luni.util.TwoKeyHashMap$Entry 432 13824 >= 23,232 

© javalang.ref FinalizerReference 298 11,920 >= 13,352 | 
© java.util. LinkedHashMapSLinkedEntry 291 9312 >= 84,968 | 
@ android.graphics.Rect 363 8,712 >= 8,824 

© java.lang.refWeakReference 354 8,496 8,696 

© org.apache.harmony.luni.util.TwoKeyHashMap$Entryl] 9 8,368 >= 31,600 E 
@ javalang.String00 5 7088 >= 63,120 

O android.graphics. Bitmap 147 7,056 >= 7,3096... 

© android.graphics.drawable.NinePatchDrawable 97 6,934 >= 9,696 

O java.util.Arraylist 280 6,720 >= 22,496 

© android.graphics.Paint 82 6,560 »= 7,576 

© android.content.res.MiuiResources$PreloadDrawableSource 258 6,192 >= 6,192 ne 


15-3 MAT 中 Histogram 的 界面 


3 com.ryg.chapter_15-conv.hprof è? sin 
i Be Er A Gr Ara ® 
i Overview | Il Histogram Ts dominator tree 5 

ss Name Shallow Heap Retained Heap Percentage a 

|  <Numeric> <Numeric> Numeric 
40 6,301,512 67.01% 

D android.graphics.Bitmap @ 0x419b9c00 48 1,048,656 11.15% 

@ class android.text.Htmi$HtmlParser @ 0x41a460d8 System Class 8 126,632 135% 

ÅA class libcore.icu.TimeZones @ 0x41856380 System Class 40 108,888 116% 

del class org.apache.harmony.security.fortress.Services @ 0x4198ba50 System Cla 32 70,280 0.75% 

¿El dass com.android.internal.R$styleable @ 0x4187f848 System Class 6,656 55,208 0.59% 

del dass android.R$styleable @ 0x418daf30 System Class 6,064 51,240 0.54% 

¿£l class android.view.View @ 0x4187dc58 System Class 1,056 46,664 0.50% 

LÌ com.android.org.bouncycastlejce.provider.BouncyCastleProvider @ 0x4199db: 112 45,064 0.48% 

D miui.content.res. ThemeZipFile @ 0x41916038 40 41,824 0.44% a 

del class android.content.res.MiuiResources @ 0x418e7e30 System Class 40 35,848 0.38% p 

@ class android.text.AutoText O 0x41a389c0 System Class 56 29,088 0.31% 

L miui.content.res.ThemeZipFile @ 0x41928050 40 20,864 0.22% 

¿El dass libcore.net.MimeUtils @ 0x41b66678 System Class 16 17,576 0.19% 

46) dass java.io.Console @ 0x418548b0 System Class 16 17,520 0.19% 

回 char[8194] @ 0x4laac420 Africa/AbidjanAfrica/AccraAfrica/Addis AbabaAfrica 16,400 16,400 0.17% 

del class libcore.icu.LocaleData @ 0x418539c8 System Class, Native Stack 8 15,856 0.17% 

¿£l dass java.lang.ref.FinalizerReference @ 0x41850188 System Class 16 13,312 0.14% 

LJ android.graphics.NinePatch @ 0x4198e250 32 13,152 0.14% 

¿El class com.android,org.bouncycastle.asn1.pkcs.PKCSObjectldentifiers @ 0x419z 504 12,816 0.14% 

de class android.media.MediaFile @ Ox4195ca88 System Class 336 11,472 0.12% 

& dass libcore.io,OsConstants @ 0241856650 System Class 1,600 11,192 0,12% 

46) class org.apache.harmony.security.utils.AlgNameMapper @ 0x41b892f0 Syster 24 11,152 0.12% 

加 dass android.view.KeyEvent @ 0x4186aae8 System Class, Native Stack 1,112 10,008 0,11% 

dÀ class com.android.¡18n.phonenumbers.PhoneNumberUtil @ 0x41a364b8 Syste 184 9,640 0.10% 

® dass android.opengl.GLES20 @ 0x418381e0 System Class 1,216 8,480 0.099% = 


图 15-4 MAT 中 Ddominator Tree 的 界面 


为 了 分 析 内 存 泄 露 ， 我 们 需要 分 析 Dominator Tree 里 面 的 内 存 信 
息 ， 在 Dominator Tree 中 内 存 泄 露 的 原因 一 般 不 会 直接 显示 出 来 ， 这 个 
时 候 需 要 按照 从 大 到 小 的 顺序 去 排查 一 遍 。 一 般 来 说 Bitmap 港 露 往往 


都 是 由 于 程序 的 某 个 地 方 发 生 了 内 存 泄露 都 引起 的 ， 在 图 15-4 中 的 第 2 
个 结果 束 是 一 个 Bitmap 泄 露 ， 选 中 它 然 后 单 击 鼠标 右键 ->Path To GC 
Roots-> exclude wake/soft references， 如 图 15-5 所 示 。 可 以 看 到 SContext 
引用 了 Bitmap 最 终 导 致 了 Bitmap 无 法 释放 ， 但 其 实 根本 原因 是 SContext 
无 法 释放 所 导致 的 ， 这 样 我 们 就 找 出 了 内 存 泄露 的 地 方 。Path To GC 
Roots 过 程 中 之 所 以 选择 排除 弱 引 用 和 软 引 用 ， 是 因为 二 者 都 有 较 大 几 
紊 被 gc 回收 掉 ， 它 们 并 不 能 造成 内 存 泄 露 。 


Class Name Shallow Heap Retained Heap 


4 |] android.graphics.Bitmap @ 0x419b9c00 
sD mBitmap android.graphics.drawable.BitmapDrawable$BitmapState @ 0x418ac188 
a "D 198] java.lang.Object[254] @ 0x41ab9d90 
4 [| mValues android.util.LongSparseArray @ 0x4190bed8 
del sPreloadedDrawables class android.content.res.Resources @ 0x4188a3cl 
“DN mBitmap android.graphics.drawable.BitmapDrawable @ 0x422c9ec8 
a Y) mCurrDrawable android.graphics.drawable.StateListDrawable @ 0x422c9cd0 
“D mBackground com.android.internal.policy.impl.PhoneWindow$DecorView @ 
4 O mDecor com.android.internal.policy.impl.PhoneWindow @ 0x422c6d90 
4 TL) mWindow com.ryg.chapter_15.MainActivity @ 0x422c6a38 


门 mOuterContext android.app.Contextimpl @ 0x422c6bf8 
= Total: 2 entries 
> Total: 2 entries 


图 15-5 Path To GC Roots 后 的 结果 


在 Dominator Tree 界 面 中 是 可 以 使 用 搜索 功能 的 ， 比 如 我 们 尝试 搜 
索 MainActivity， 因 为 这 里 我 们 已 经 知道 MainActivity 存 在 内 存 泄露 
了 ， 搜 索 后 的 结果 如 图 15-6 所 示 。 我 们 发 现 里 面 有 6 个 MainActivity 的 
对 象 ， 这 是 因为 每 次 按 back 键 退出 再 重新 进入 MainActivity， 系 统 都 会 
重新 创建 一 个 新 的 MainActivity， 但 是 由 于 老 的 MainActivity 无 法 被 回 
收 ， 所 以 就 出 现 了 多 个 MainActivity 对 象 的 情形 。 男 外 MAT 还 有 很 多 其 
他 功能 ， 这 里 就 不 再 一 一 介绍 了 ， 请 读者 自己 体验 吧 。 


g com.ryg.chapter_15-conv.hprof 23 
ito ely Br dA > Br carl] al 


i Overview| Il Histogram Pe dominator tree 22% path2gc [selection of 'Bitmap @ 0x419b9c00'] -excludes java.lang.ref.WeakReferen 


Class Name Shallow Heap Retained Heap Percentage 
4P *MainActivity.* <Numeric> <Numeric>  <Numeric> 
com.ryg.chapter_15.MainActivity @ 0x42290018 184 2,200 0.02% 

LJ com.ryg.chapter_15.MainActivity @ 0x42292300 184 2,200 0.02% 
_ com.ryg.chapter_15.MainActivity @ 0x422bfb38 184 2,200 0.02% 
L] com.ryg.chapter_15.MainActivity @ 0x422c6a38 184 2,200 0.02% 
com.ryg.chapter_15.MainActivity @ 0x422b2338 184 2,176 0.02% 

L com.ryg.chapter_15.MainActivity O 0x422alaa0 184 2,128 0.02% 
LJ java.lang.String @ 0x42290358 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
J java.lang.String @ 0x422925e0 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
U) java.lang.String @ 0x422a2d10 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
J java.lang.String @ 0x422b9510 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
java.lang.String O 0x422c0410 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 

L java.lang.String @ 0x422c7310 com.ryg.chapter_15/com.ryg.chapter_15.MainA 24 136 0.00% 
¿£l class com.ryg.chapter_15.MainActivity @ 0x422a1530 System Class 16 104 0.00% 
à] java.lang.String @ 0x422a1a50 MainActivity Unknown 24 64 0.00% 


> Total: 14 entries (12,872 filtered) 


图 15-6 Dominator Tree 的 搜索 功能 


15.3 ”提高 程序 的 可 维护 性 


本 世 所 讲述 的 内 容 是 Android 的 程序 设计 思想 ， 主 旨 和 是 如 何 提高 代 
码 的 可 维护 性 和 可 扩展 性 ， 而 程序 的 可 维护 性 本 质 上 也 包含 可 扩展 
性 。 本 节 的 切入 点 为 : 代码 风格 、 代 码 的 层次 性 和 单一 职 贡 原则 、 面 
癌 扩展 编程 以 及 设计 模式 ， 下 面 围绕 着 它们 分 别 展开 。 


可 读 性 是 代码 可 维护 性 的 前 提 ， 一 段 别 人 很 难 读 懂 的 代码 的 可 维 
护 性 显然 是 极 过 的 。 而 恨 好 的 代码 风格 在 一 定 程度 上 可 以 提高 程序 的 
可 读 性 。 代 码 风 格 包 含 很 多 方面 ， 比 如 命名 规范 、 代 码 的 排版 以 及 十 
否 写 注释 等 。 到 发 什么 样 的 代码 风格 是 民 好 的 ? 这 是 个 仁者 见 仁 的 问 
题 ， 下 面 是 笔者 的 一 些 看 法 。 


(1) 命名 要 规范 ， 要 能 正确 地 传达 出 变量 或 者 方法 的 含义 ， 少 用 
缩写 ， 关 于 变量 的 前 缀 可 以 参考 Android 源 码 的 命名 方式 ， 比 如 私有 成 
员 以 m 开 头 ， 静 态 成 员 以 s 开 头 ， 第 量 则 全 部 用 大 写字 母 表示 ， 等 等 。 


(2) 代码 的 排版 上 需要 留 出 合理 的 空白 来 区 分 不 同 的 代码 块 ， 其 
中 同类 变量 的 声明 要 放 在 一 组 ， 两 类 变量 之 间 要 留 出 一 行 空 日 作为 区 


分 。 


(3) 仅 为 非常 关键 的 代码 添加 注释 ， 其 他 地 方 不 写 注释 ， 这 就 对 
变量 和 方法 的 命名 风格 提出 了 很 高 的 要 求 ， 一 个 合理 的 命令 风格 可 以 
让 读者 阅读 源码 就 像 在 阅读 注释 一 样 ， 因 此 根本 不 需要 为 代码 额外 写 
注释 。 


代码 的 层次 性 钙 指 代码 要 有 分 层 的 概念 ， 对 于 一 段 业务 逻辑 ， 不 
要 试图 在 一 个 方法 或 者 一 个 类 中 去 全 部 实现 ， 而 要 将 它 分 成 几 个 子 逻 
辑 ， 然 后 每 个 子 逻 辑 做 目 己 的 事情 ， 这 样 既 显 得 代码 层次 分 明 ， 叉 可 
以 分 解 任务 从 而 实现 简化 逻辑 的 效果 。 单 一 职责 是 和 层次 性 相关 联 
的 ， 代 码 分 层 以 后 ， 每 一 层 仪 仪 天 注 少 量 的 逻辑 ， 这 样 束 做 到 了 单一 
职责 。 代 码 的 层次 性 和 单一 职责 原则 可 以 以 公司 的 组 织 结构 为 例 来 说 
了 明 ， 比 如 现在 有 一 个 复杂 的 需求 来 到 了 部 门 经 理 面前 ， 如 采 部 门 经 理 
需要 给 每 个 员工 来 安排 具体 的 任务 ， 那 显然 他 会 显得 很 索 ， 因 为 他 必 
须要 了 解 每 个 员工 的 工作 并 最 终 收 集 每 个 员工 的 完成 情况 ， 这 个 时 候 
整个 工作 过 程 豆 缺少 了 层次 性 ， 并 且 也 违 育 了 单一 职责 的 原则 ， 毕 竟 
经 理 的 主要 工作 是 管理 团队 而 不 是 给 员工 安排 任务 。 如 采 采 用 分 层 的 
思想 要 怎么 做 呢 ? 首先 经 理 可 以 将 复杂 的 任务 分 成 看 干 份 ， 每 一 份 交 
给 一 个 主管 处 理 ， 然 后 剩 下 的 事情 经 理 就 不 用 管 了 ， 他 只 需要 管理 主 
管 即 可 。 对 于 主管 来 疝 ， 分 配给 他 的 任务 相对 于 整个 任务 承 简 单 了 不 
少 ， 这 个 时 候 他 再 拆 解 任务 给 组 员 ， 这 个 时 候 真 正 到 达 组 员 手 里 的 任 
务 其 实 就 没有 那么 复杂 了 ， 这 其 实 类 似 于 分 治 策略 。 这 样 一 来 整个 工 
作 过 程 束 具有 了 三 层 的 结构 ， 并 且 每 一 层 有 不 同 的 职责 ， 一 旦 出 现 了 
错误 也 可 以 很 方便 地 定位 到 具体 的 地 方 。 


程序 的 扩展 性 标志 着 开发 人 员 是 否 有 足够 的 经 验 ， 很 多 时 候 在 开 
发 过 程 中 我 们 无 法 保证 已 经 做 好 的 需求 不 在 后 面 的 版 本 发 生变 更 ， 
此 在 写 程序 的 过 程 中 要 时 刻 考 虑 到 扩展 ， 考 虑 着 如 果 这 个 逻辑 后 面 发 
生 了 改变 那么 需要 做 哪些 修改 ， 以 及 怎么 样 才能 降低 修改 的 工作 量 ， 
面 问 扩展 编程 会 使 程序 具有 很 好 的 扩展 性 。 


恰当 地 使 用 设计 模式 可 以 提高 代码 的 可 维护 性 和 可 扩展 性 ， 但 是 
Android 程 序 容易 有 性 能 瓶 贷 ， 因 此 要 控制 设计 的 度 ， 设 计 不 能 太 率 
强 ， 否 则 束 是 过 度 设 计 了 “。 篆 见 的 设计 模式 有 很 多 ， 比 如 单 例 模式 、 
工厂 模式 以 及 观察 者 模式 等 ， 由 于 本 书 不 是 专门 介绍 设计 模式 的 书 ， 
因此 这 里 就 不 对 设计 模式 进行 详细 的 介绍 了 ， 读 者 可 以 参看 《大 话 设 
计 模 式 》 和 《Android 源 码 设计 模式 解析 与 实战 》 这 两 本 书 ， 另 外 设计 
模式 需要 理解 后 灵活 运用 才能 发 挥 更 好 的 效果 。 
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电子 工业 出 版 社 依 法 对 本 作品 至 有 专 有 出 版 权 。 任 何 未 经 权利 人 
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